From nobody Tue Apr 1 05:16:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CF61A068C for ; Tue, 1 Apr 2014 05:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 IMeUPuxkdrUt for ; Tue, 1 Apr 2014 05:16:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 460A41A067F for ; Tue, 1 Apr 2014 05:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3343; q=dns/txt; s=iport; t=1396354563; x=1397564163; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=XIVSy6jG2ZaHcGOtgSk0GOEMWO/ZhCgou5ndFYYMWG0=; b=MVi5w2O6DoXJhfxk6M5u4oPPqtDFprj0zaL9/elVvS/VP2B9Pf3NIzEm nHZVJGrnINlf6EMw9sSra2tUW2urA4toeQNnpxzKnMZd9Awrccm+swOko iBAzkSo18V2A4Ti/vJ2Ux4kWLcgHdQoK52CnMu/gHXy3ZhQPuxmKEf264 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAN2sOlOtJA2L/2dsb2JhbABZgwY7V8NJgR0WdIIlAQEBAwEdClIMBgEIEQQBAQsODzkUCQkBBAENBQiHaQjRVxeOJxgxDRKDDIEUBIkekGuRBoMwgWpB X-IronPort-AV: E=Sophos;i="4.97,772,1389744000"; d="scan'208";a="314377957" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 01 Apr 2014 12:16:02 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s31CG1Yp029698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Apr 2014 12:16:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.121]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 07:16:01 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Oleg Moskalenko , Jonathan Lennox Thread-Topic: [tram] STUN hash agility Thread-Index: Ac9NpA/jehg99zOeS0eETll24RI7Hw== Date: Tue, 1 Apr 2014 12:15:59 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242FD59D@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.236] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_kfEzdSN2ezWsuPNKcWVvD7yD78 Cc: "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 01 Apr 2014 12:16:09 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Friday, March 28, 2014 6:17 PM > To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko; Jonathan Lennox > Cc: tram@ietf.org > Subject: Re: [tram] STUN hash agility >=20 > Oooooh! I love playing the devil's advocate... :) :) >=20 > Le 2014-03-28 05:16, Tirumaleswar Reddy (tireddy) a =E9crit : > > 1)TURN Server has to maintain the {username/realm/password} database > > just like the AD server which is an overhead. >=20 > Are you assuming that the TURN server cannot query the AD server instead > of maintaining a duplicate database ? TURN server can query the AD server. But this will be not be the typical re= quest/response used, in this case the request must contain (username, realm= ) asking for the password. >=20 > In any case, database replication is easy and well understood. You need > to have *lots* of accounts for e.g. dead-simple MySQL replication to not > be sufficient. Or the TURN server can establish connection with remote RDMS server and sen= d query to get the password. >=20 > > 2)In a large Enterprise Network (for e.g. consider a large service > > company) where NNN number of new users join, MMM users leave every day. > > It seems difficult to manage this credential database on the TURN serve= r > > to be in sync with the AD. >=20 > Really? MySQL replication (for example) is dead simple. >=20 > > 3)If each branch office in an large enterprise network wants to deploy > > TURN servers, then the cost of TURN server includes additional storage > > space and operational issues which may be a concern of the > > I.T. >=20 > I doubt this very much. You would need *lots* of user accounts for the > password database to not fit on any regular-sized hard drive. >=20 > About operations: once again, database replication is well understood > and very common. Database replication will work but it's an overhead in the above use case. = In service based companies, where onboarding/off-boarding of users on daily= basis is frequent, this would call for frequent database replication. If = branch offices want TURN server to be co-located with a router, it may not= even have hard-drive to store this info. With the current limitation, soft= ware upgrade of the router to support TURN server will not be sufficient. I= .T will also have to purchase routers which come up hard drive.=20 Further a small branch/sales office of an Enterprise network may have only = few hundred users in that site, it's an over-head to replicate the credenti= als of the entire org to this small site. >=20 > > 4)AD server maintained in the Data Center usually has better physical > > security than branch offices - what if someone breaks into the branch > > office and steals all the username + password ? (I am assuming the > > username, password are the same credentials used to access other > > critical enterprise resources) >=20 > Now this I totally buy. We need something better than > MD5(username:realm:password). Cheers, -Tiru >=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 nobody Fri Apr 4 02:55:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87BA1A012B for ; Fri, 4 Apr 2014 02:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.064 X-Spam-Level: * X-Spam-Status: No, score=1.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r746bQqNRJ_C for ; Fri, 4 Apr 2014 02:54:59 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 172221A004D for ; Fri, 4 Apr 2014 02:54:59 -0700 (PDT) Received: from [IPv6:2001:5c0:1101:2d00:b5a5:a0b8:9458:72a0] (unknown [IPv6:2001:5c0:1101:2d00:b5a5:a0b8:9458:72a0]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 726F22084B for ; Fri, 4 Apr 2014 11:54:53 +0200 (CEST) Message-ID: <533E816B.1020204@acm.org> Date: Fri, 04 Apr 2014 03:54:51 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PLdvq1aQ2mmF4fZi743GwpzYIvY Subject: [tram] Open issue #4: domain/ip address handling in stun-dtls [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:55:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I did not receive any comment on this proposal, so I am resubmitting it here: Following the discussion in the TRAM session in London about the domain/ip address handling for STUN over DTLS, we discussed what to do in the draft, and came with an alternate solution that could be better than the conclusion in the session (which was to forbid IP addresses). Because IP addresses are already accepted when TLS will be used with a STUN/TURN URI, that would require a document modifying 7064/65 to change that also for DTLS. As a reminder, here's the text in RFC 5389: "The client MUST verify the identity of the server. To do that, it follows the identification procedures defined in Section 3.1 of RFC 2818 [RFC2818]. Those procedures assume the client is dereferencing a URI. For purposes of usage with this specification, the client treats the domain name or IP address used in Section 8.1 as the host portion of the URI that has been dereferenced. Alternatively, a client MAY be configured with a set of domains or IP addresses that are trusted; if a certificate is received that identifies one of those domains or IP addresses, the client considers the identity of the server to be verified." The problem here is when the IP address has been resolved before the URI was created, which will be the case most of the time in the WebRTC server. What we would suggest is to to add a new member in the RTCIceServer dictionary to carry the domain name (names?) to validate in case IP addresses are used in the STUN/TURN URI (pretty much like what was done for the username and password). Comments? On 03/24/2014 01:37 PM, Gonzalo Salgueiro (gsalguei) wrote: > Hi - > > We have posted two new versions of the draft today. The -00 was the WG > adopted with text unchanged from draft-petithuguenin-tram-stun-dtls-00. > > This -01 version addresses the open issues we came to consensus on during > the meeting in London. > > Changes > from -00 to -01 are: > > - Updated the mandatory cipher suites. - Added a new open item to determine > if we want to specify favoring cipher suites which support PFS over non-PFS > cipher suites. - Closed remaining opening items from previous draft. > > > We will be sending some emails shortly to discuss a few open issues we'd > like to tackle before an -02. > > Thanks, > > Gonzalo > > On Mar 24, 2014, at 3:26 PM, internet-drafts@ietf.org > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the TURN Revised and Modernized >> Working Group of the IETF. >> >> Title : Datagram Transport Layer Security (DTLS) as Transport >> for Session Traversal Utilities for NAT (STUN) Authors : Marc >> Petit-Huguenin Gonzalo Salgueiro Filename : >> draft-ietf-tram-stun-dtls-01.txt Pages : 14 Date : >> 2014-03-24 >> >> Abstract: This document specifies the usage of Datagram Transport Layer >> Security (DTLS) as a transport protocol for Session Traversal Utilities >> for NAT (STUN). It provides guidances on when and how to use DTLS with >> the currently standardized STUN Usages. It also specifies modifications >> to the STUN URIs and TURN URIs and to the TURN resolution mechanism to >> facilitate the resolution of STUN URIs and TURN URIs into the IP address >> and port of STUN and TURN servers supporting DTLS as a transport >> protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-dtls-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJTPoFoAAoJECnERZXWan7EQQEP/jzWhAKx+iBQtMwd/2pP9jiX ty+LfH9qnd8GdspeqZAR9KgozCJhSW1eZi0D4dh3uhJUHcrP0noYjJHyJM5A5q/a aL48G6xEOkg+hfbJ4a0hNFRCxV6XC4Aj4qr+gH7bxRKX1buA1x6M0rv1n/mMiuig bz9QFYyQUnyy9TI7C4oQJbvxrJyp+T8NPY8hpgs4ndwC5ogVdbCq2cD6mWoMgUoZ qaQovHk9RdSGOsqjDJ3iJi3Kx73B0cmmB174vVW22yXlAhkLr7szhVbpkwKfa92W lxcnxQn8VuT5bEsw3VPOVlWlAbfj8E1RhrRpRa3E9sedsziXZM+iBnPaz8HBihhN uUZpxRp2agu57NmaPrRRSWE+oM03zSDHdIYjXDCI9UcjPYXZHSavlzjw4a+2d8MH m9m1C0P+h9UGMO8pn/21UK3yDGWfGuXZGZDYYzlo2BWYMjLiFnctP+h7WNWEeTWw LKhf7r2nZj4qbNGlDxMLAay5pb2WjCETd/Rg5rHLjy/WcOcPeMO69mk2BzEwf0gy V1CmHYb39cMAoy5C9oM7Cc8r9qXUzX/vPdItWEsDtPoXt1ixr2IpP2MhmsSEHqo7 ad7kiiOE8KElAyuY7o5QuRAzRCLA+bVwTbyf+Qa38F3Tz1dNpCaiQOiTfFzGJ9Vw IEYWndljPyjbkmJfMai6 =JhQ+ -----END PGP SIGNATURE----- From nobody Fri Apr 4 02:59:42 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BB71A0059 for ; Fri, 4 Apr 2014 02:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.064 X-Spam-Level: * X-Spam-Status: No, score=1.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_xs0s-Tyihu for ; Fri, 4 Apr 2014 02:59:38 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 005CA1A004D for ; Fri, 4 Apr 2014 02:59:37 -0700 (PDT) Received: from [IPv6:2001:5c0:1101:2d00:b5a5:a0b8:9458:72a0] (unknown [IPv6:2001:5c0:1101:2d00:b5a5:a0b8:9458:72a0]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 2645D2084B for ; Fri, 4 Apr 2014 11:59:33 +0200 (CEST) Message-ID: <533E8283.7030509@acm.org> Date: Fri, 04 Apr 2014 03:59:31 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/V7xKBeWHEVm4ZEuRQszZfIHpIXE Subject: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:59:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 An issue that was discussed in London was ALPN registration in the DTLS draft. After discussion, we think that this is not specific to DTLS, so perhaps it is a better idea to have this registration either in a separate document or in the future STUN-bis. Comments? On 03/24/2014 01:37 PM, Gonzalo Salgueiro (gsalguei) wrote: > Hi - > > We have posted two new versions of the draft today. The -00 was the WG > adopted with text unchanged from draft-petithuguenin-tram-stun-dtls-00. > > This -01 version addresses the open issues we came to consensus on during > the meeting in London. > > Changes > from -00 to -01 are: > > - Updated the mandatory cipher suites. - Added a new open item to > determine if we want to specify favoring cipher suites which support PFS > over non-PFS cipher suites. - Closed remaining opening items from previous > draft. > > > We will be sending some emails shortly to discuss a few open issues we'd > like to tackle before an -02. > > Thanks, > > Gonzalo > > On Mar 24, 2014, at 3:26 PM, internet-drafts@ietf.org > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the TURN Revised and >> Modernized Working Group of the IETF. >> >> Title : Datagram Transport Layer Security (DTLS) as Transport >> for Session Traversal Utilities for NAT (STUN) Authors : Marc >> Petit-Huguenin Gonzalo Salgueiro Filename : >> draft-ietf-tram-stun-dtls-01.txt Pages : 14 Date : >> 2014-03-24 >> >> Abstract: This document specifies the usage of Datagram Transport Layer >> Security (DTLS) as a transport protocol for Session Traversal Utilities >> for NAT (STUN). It provides guidances on when and how to use DTLS with >> the currently standardized STUN Usages. It also specifies modifications >> to the STUN URIs and TURN URIs and to the TURN resolution mechanism to >> facilitate the resolution of STUN URIs and TURN URIs into the IP address >> and port of STUN and TURN servers supporting DTLS as a transport >> protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-dtls-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJTPoJ/AAoJECnERZXWan7ETV0QAMhE9ESbQNU6YlwezchGjXFW OGbXPI/Yx8X+XfQqsFDCUZzTXA1/JlVPcvcKy2PI0SjyuuF1HW8pGJSE9T6pONvI 5FcinQd6aYyOWzkRnpdcRUmPiiVNxxZMyTuXCEsnBZXfdqX3llSW2bMExHDn7ACg Edv3fRwMUW231bu0QVnugYFdpPzJ5POoosmi4b4lHWcFQpn1CMZu3BId1CMH/fFn W7+NL3yZauw8ProSANOLNo5WR7Af9S5blwP+xSlkxp1qveVGs6wZIrOf2C1pAFWE +z5KEiM5H8pz4kqANni0SlkXSypDFgBL43Wlaeu/POrSb0qVew3W1bQ2bLmlD+G4 VU5Kk/82kEsb/kIv+ezwDMKL5kGR+hzsohr63b1P0r9zeI/8lEfuZ0V6L4/y5b2K 8kHDOxGw3CU9UZ24cCR81x0a3TuSmF6QdRc246K3RWLwZVLl5oo9ZNhf74RQeHV/ PQrDESb5ZPLn5cUPEfxqFNrF52BcB8cOaGgMvr86XlHkVpr10b4/7Y0ZAwu/m6xI 6Mxs2BG2ioMFgVSwtqC0E7hoZV+pNgjDHLMCyJQS5XDzmG5XQnIeQzUB1iwO3sHK 1N6I1qGwMaz3ANUPlt1UY8kILoQerYLZ10Bq6sPKKL1pg1m6DyIbwVEUnr6l6Qzl Pft3IBOj/oqn+N4QLNWK =UADl -----END PGP SIGNATURE----- From nobody Fri Apr 4 06:26:38 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6157A1A0192 for ; Fri, 4 Apr 2014 06:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 o0d42D7EJbmr for ; Fri, 4 Apr 2014 06:26:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF471A0174 for ; Fri, 4 Apr 2014 06:26:32 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1002] (unknown [IPv6:2620:0:230:2001::1002]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 336654043F for ; Fri, 4 Apr 2014 09:26:27 -0400 (EDT) Message-ID: <533EB302.10107@viagenie.ca> Date: Fri, 04 Apr 2014 09:26:26 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E816B.1020204@acm.org> In-Reply-To: <533E816B.1020204@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OUdRyQF_9wZ7utZ1iheFFDEw5QQ Subject: Re: [tram] Open issue #4: domain/ip address handling in stun-dtls [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 13:26:37 -0000 Le 2014-04-04 05:54, Marc Petit-Huguenin a écrit : > What > we would suggest is to to add a new member in the RTCIceServer dictionary to > carry the domain name (names?) to validate in case IP addresses are used in > the STUN/TURN URI (pretty much like what was done for the username and password). So if the client always has access to the domain name, why wouldn't it always resolve by itself? I would be very tempted to write this simple pseudocode: char *hostname; if (is_a_domain_name(uri_host)) hostname = uri_host; else hostname = rtciceserver_host; resolve_and_connect(hostname); Simon From nobody Fri Apr 4 06:37:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E011A01AB for ; Fri, 4 Apr 2014 06:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wTp1zUhSr4-N for ; Fri, 4 Apr 2014 06:37:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DE86B1A01B1 for ; Fri, 4 Apr 2014 06:37:08 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1002] (unknown [IPv6:2620:0:230:2001::1002]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 425504043F for ; Fri, 4 Apr 2014 09:37:04 -0400 (EDT) Message-ID: <533EB57F.6020707@viagenie.ca> Date: Fri, 04 Apr 2014 09:37:03 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> In-Reply-To: <533E8283.7030509@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/JtT832c8vCPV9mM9GYe5tgFM_Fk Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 13:37:14 -0000 Le 2014-04-04 05:59, Marc Petit-Huguenin a écrit : > An issue that was discussed in London was ALPN registration in the DTLS draft. > After discussion, we think that this is not specific to DTLS, so perhaps it > is a better idea to have this registration either in a separate document or in > the future STUN-bis. Doesn't matter. What goes in STUN-bis is irrelevant. For what it's worth, we could even decide that STUN-bis will include and obsolete stun-dtls completely. STUN-bis is a longer-term, broader scope effort. We need functional [D]TLS today, and that includes ALPN IMHO. Simon From nobody Fri Apr 4 09:59:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B881A025E for ; Fri, 4 Apr 2014 09:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 duBjik12dEz0 for ; Fri, 4 Apr 2014 09:59:42 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE4A1A026E for ; Fri, 4 Apr 2014 09:59:42 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8B2D72868C for ; Fri, 4 Apr 2014 16:59:37 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 7920C2866C for ; Fri, 4 Apr 2014 16:59:37 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 157FB2026 for ; Fri, 4 Apr 2014 16:59:36 +0000 (GMT) Message-ID: <533EE4F7.1020701@akamai.com> Date: Fri, 04 Apr 2014 12:59:35 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <20140404165719.31339.3827.idtracker@ietfa.amsl.com> In-Reply-To: <20140404165719.31339.3827.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140404165719.31339.3827.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Ofy_MAFpkA2YJwB12PN8sj82rcQ Subject: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 16:59:47 -0000 Hi all, I have just submitted the following draft that describes a peer-specific redirection mechanism for TURN. Comments would be appreciated. Cheers, --Brandon -------- Original Message -------- Subject: New Version Notification for draft-williams-peer-redirect-00.txt Date: Fri, 4 Apr 2014 12:57:19 -0400 From: internet-drafts@ietf.org To: Williams, Brandon , Tirumaleswar Reddy , Tirumaleswar Reddy , Williams, Brandon A new version of I-D, draft-williams-peer-redirect-00.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Name: draft-williams-peer-redirect Revision: 00 Title: Peer-specific Redirection for Traversal Using Relays around NAT (TURN) Document date: 2014-04-04 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-00.txt Status: https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ Htmlized: http://tools.ietf.org/html/draft-williams-peer-redirect-00 Abstract: This specification describes a peer-specific redirection method that allows the TURN server to redirect a client for the purpose of improving communication with a specific peer without negatively affecting communication with other peers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Apr 4 10:35:36 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07C01A023E for ; Fri, 4 Apr 2014 10:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Kzf5W0EnJfUE for ; Fri, 4 Apr 2014 10:35:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE6EE1A023B for ; Fri, 4 Apr 2014 10:35:27 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1002] (unknown [IPv6:2620:0:230:2001::1002]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CDA5640402 for ; Fri, 4 Apr 2014 13:35:22 -0400 (EDT) Message-ID: <533EED5A.1020409@viagenie.ca> Date: Fri, 04 Apr 2014 13:35:22 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140404165719.31339.3827.idtracker@ietfa.amsl.com> <533EE4F7.1020701@akamai.com> In-Reply-To: <533EE4F7.1020701@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/zrchzah3rhAq0KNI2VcD3xi1lOU Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 17:35:34 -0000 Le 2014-04-04 12:59, Brandon Williams a écrit : > I have just submitted the following draft that describes a peer-specific > redirection mechanism for TURN. Comments would be appreciated. Interesting! I found the problem statement very clear. As I was reading it I imagined a simple solution. When I got to the solution description I was a bit surprised by its complexity. - Why is CHECK-ALTERNATE needed? (I think I can guess why, but this needs to be spelled out in any case.) - Why is XOR-OTHER-ADDRESS needed? Without it, each of your peer's candidates would be redirected or not independently. For example, a peer's server-reflexive candidate could be located very far from a peer's relayed candidate and end up going through a different TURN server. Why do they need to go through the same server? What's wrong with being redirected to different servers for different candidates? Non-technical comments to be sent unicast shortly... Simon From nobody Fri Apr 4 10:59:05 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFC21A03D1 for ; Fri, 4 Apr 2014 10:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 jqoSXnkla2wg for ; Fri, 4 Apr 2014 10:58:59 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 66DE81A0218 for ; Fri, 4 Apr 2014 10:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1034; q=dns/txt; s=iport; t=1396634335; x=1397843935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UkdMIz+INVxt+of5VgcgV4KZRg2TeoL6MZIdr/zEVs0=; b=CQxx0KsjFXeRo0kmLildxtpTcsCILud4DRUvovoJI2XpStl4z7zsv6PQ kbNLqtZevVBwfbhysw/lqjPedE72OWeThuCJINCSiKf7hyd877Dh2MWId fQKu0t6rRC13Xc6orEgAFaHnyDv66ga+5USxhSe3fpqY98y/xT0Y81zQ8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADTyPlOtJV2c/2dsb2JhbABZgwY7V7xXhzeBJBZ0giUBAQEDAQEBAWsLBQsCAQhGJwslAgQOBYdxCA3QMxMEjh0hMweDJIEUBIkijzmSP4FxgT+CKw X-IronPort-AV: E=Sophos;i="4.97,796,1389744000"; d="scan'208";a="33113924" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 04 Apr 2014 17:58:54 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s34Hws5Q005651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 17:58:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.185]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 4 Apr 2014 12:58:54 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Simon Perreault Thread-Topic: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: AQHPT+yZJikTBgKlDUC8PeejTqIjLZsByeWAgABJJ4A= Date: Fri, 4 Apr 2014 17:58:53 +0000 Message-ID: <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> In-Reply-To: <533EB57F.6020707@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.218.190] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <51B36CAB9B1D8A49901B4B542D4B6904@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/YPWuwjMvl5E5gVQfnNKoBgk369o Cc: "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 17:59:04 -0000 Understood. Nonetheless, even if not a part of STUNbis, it doesn't seem it= should be buried in STUNoDTLS. Shall we produce a dedicated draft for thi= s? -G On Apr 4, 2014, at 9:37 AM, Simon Perreault w= rote: > Le 2014-04-04 05:59, Marc Petit-Huguenin a =E9crit : >> An issue that was discussed in London was ALPN registration in the DTLS = draft. >> After discussion, we think that this is not specific to DTLS, so perhap= s it >> is a better idea to have this registration either in a separate document= or in >> the future STUN-bis. >=20 > Doesn't matter. What goes in STUN-bis is irrelevant. For what it's worth,= we could even decide that STUN-bis will include and obsolete stun-dtls com= pletely. STUN-bis is a longer-term, broader scope effort. We need functiona= l [D]TLS today, and that includes ALPN IMHO. >=20 > Simon >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Apr 4 11:00:51 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3682B1A0235 for ; Fri, 4 Apr 2014 11:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 c6rcfWxxaW70 for ; Fri, 4 Apr 2014 11:00:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id ACDC51A04BC for ; Fri, 4 Apr 2014 11:00:37 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1002] (unknown [IPv6:2620:0:230:2001::1002]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EC45440402; Fri, 4 Apr 2014 14:00:32 -0400 (EDT) Message-ID: <533EF340.40800@viagenie.ca> Date: Fri, 04 Apr 2014 14:00:32 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> In-Reply-To: <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/TuWoAqUbm3eVN6J8Ke2rHP-f7Sk Cc: "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 18:00:50 -0000 Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a écrit : > Understood. Nonetheless, even if not a part of STUNbis, it doesn't seem it should be buried in STUNoDTLS. Shall we produce a dedicated draft for this? My preference would be for "buried in STUNoDTLS". :) But I'm open to arguments for a dedicated draft. Simon From nobody Fri Apr 4 11:09:35 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7C51A0265 for ; Fri, 4 Apr 2014 11:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 h0hOWKm1M9SV for ; Fri, 4 Apr 2014 11:09:30 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0811A022B for ; Fri, 4 Apr 2014 11:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=730; q=dns/txt; s=iport; t=1396634965; x=1397844565; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jJCvfpC37bRpyLTQPGNIxp4bdUf6HHwdbclknizBeK8=; b=JZcdNFVV1tKB+b8Q/b8T4oESguQ/RUvtqIL5PH4QgvpRlJS/FZg674md d728eT8Nyxj7dEes66SsWtB/TropsQp8kR/27pZqjUvuV/u8rpNJodQzj 17qRHQAtEzKeY6104D/RzUvxV9xckYMudx8Pv0zICgUPl+tgqoJ52AXyn k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMD0PlOtJA2F/2dsb2JhbABZgwaBEsQOgSQWdIIlAQEBAwEpUAULAgECBkYyJQIEDgWHcQjQRReOPjMHgySBFAEDiSKPOZI/gXGBP4Ir X-IronPort-AV: E=Sophos;i="4.97,796,1389744000"; d="scan'208";a="33117333" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP; 04 Apr 2014 18:09:25 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s34I9Pq8024579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 18:09:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.185]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 4 Apr 2014 13:09:25 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Simon Perreault Thread-Topic: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: AQHPT+yZJikTBgKlDUC8PeejTqIjLZsByeWAgABJJ4CAAAB2AIAAAnsA Importance: high X-Priority: 1 Date: Fri, 4 Apr 2014 18:09:24 +0000 Message-ID: <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> In-Reply-To: <533EF340.40800@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.218.190] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nQeYchtqbma6qw5ZuhTEGrbZCh0 Cc: "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 18:09:34 -0000 On Apr 4, 2014, at 2:00 PM, Simon Perreault w= rote: > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit : >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't seem= it should be buried in STUNoDTLS. Shall we produce a dedicated draft for = this? >=20 > My preference would be for "buried in STUNoDTLS". :) But I'm open to argu= ments for a dedicated draft. My position is that the ALPN reg is entirely independent of STUNoDTLS, whic= h is why we considered more contextually relevant for the broader STUNbis e= ffort. A standalone dedicated ALPN reg doc to point to seems cleaner to me= , but I'm open to WG decision on this. -G >=20 > Simon From nobody Fri Apr 4 12:32:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468251A0547 for ; Fri, 4 Apr 2014 12:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 xi0CF9d7cELT for ; Fri, 4 Apr 2014 12:31:51 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3AF1A05C3 for ; Fri, 4 Apr 2014 12:31:25 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2C15C286A0 for ; Fri, 4 Apr 2014 19:31:21 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 1912C2869E for ; Fri, 4 Apr 2014 19:31:21 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id A57B28007C for ; Fri, 4 Apr 2014 19:31:20 +0000 (GMT) Message-ID: <533F0886.4020201@akamai.com> Date: Fri, 04 Apr 2014 15:31:18 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140404165719.31339.3827.idtracker@ietfa.amsl.com> <533EE4F7.1020701@akamai.com> <533EED5A.1020409@viagenie.ca> In-Reply-To: <533EED5A.1020409@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/LiLkTZa3xwwmVv1B3Fav5jbsbp4 Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 19:31:59 -0000 Thanks for the comments Simon. re: CHECK-ALTERNATE CHECK-ALTERNATE serves two purposes: backward compatibility and client flexibility. The client flexibility goal is spelled out in the introduction, though I can see that the relationship between that statement and the definition of the attribute isn't clearly stated. i see now that the backward compatibility (prevent transmission of the ALTERNATE-SERVER attribute to a client that doesn't support this use) isn't stated anywhere. I'll be sure to clarify those points in the next revision. re: XOR-OTHER-ADDRESS In a case where both clients to use TURN servers, you want them to converge as quickly as possible on the pair that will provide the best performance. Typically, the system will attempt to get them to use the same relay server. If each one picks the TURN server that is best based on its peer's relay address but the relay server was a bad pick in the first place, then you'll frequently end up with a bad alternate and never converge on a good pair. I think it requires a more complicated example than the one in the introduction to really spell this out. Consider this case (T == TURN relay; P == peer): T1 <-- P1 T2 P2 --> T3 If T1, T2, and T3 are all part of the same system and P2 asks T3 for an alternate server to get to T1, the system will most likely send it to T1 in order to avoid unnecessary relay hops. Likewise, if P1 asks T1 for an alternate to T3, it will get T3. They would get a more optimal end-to-end connection, but not the best end-to-end connection, since in this case, you want them to converge on T2. I think you could probably get to the same decision using the combined set of responses for both the server-reflexive candidate and the relayed candidate, but I think that the addition of this attribute can help the system to get you there faster. Do you have thoughts on this rationale? If it seems reasonable, then I'll add some detail about it to the next revision. --Brandon On 04/04/2014 01:35 PM, Simon Perreault wrote: > Le 2014-04-04 12:59, Brandon Williams a écrit : >> I have just submitted the following draft that describes a peer-specific >> redirection mechanism for TURN. Comments would be appreciated. > > Interesting! > > I found the problem statement very clear. As I was reading it I imagined > a simple solution. When I got to the solution description I was a bit > surprised by its complexity. > > - Why is CHECK-ALTERNATE needed? (I think I can guess why, but this > needs to be spelled out in any case.) > > - Why is XOR-OTHER-ADDRESS needed? Without it, each of your peer's > candidates would be redirected or not independently. For example, a > peer's server-reflexive candidate could be located very far from a > peer's relayed candidate and end up going through a different TURN > server. Why do they need to go through the same server? What's wrong > with being redirected to different servers for different candidates? > > Non-technical comments to be sent unicast shortly... > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Apr 4 13:17:31 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A611A0442 for ; Fri, 4 Apr 2014 13:17:28 -0700 (PDT) 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 6SpCMEJcGfjk for ; Fri, 4 Apr 2014 13:17:24 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 933261A0238 for ; Fri, 4 Apr 2014 13:17:24 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id p10so3786218pdj.12 for ; Fri, 04 Apr 2014 13:17:20 -0700 (PDT) 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=H6yXj6m4+GWKWjlbsVjiAMMU9W+SiZwlEXgvQJ5beMY=; b=Cx4bmOaRbtXPNU7yy/e65m+M0G0V7ukZeMzNZgI1oGtHIu83Yao+oxyHrV78M5JIv3 +INbXAIeU3njZXBq8XcT+SnV6rhMpV9TWAiCJv+bZNJgQhtItDydY9Jee8THaQtboHtM h7pge0H4RJU9hhaWPNCbiYLwWF0jpncfcPfX6IEFgUSWYtlzsdRVKnCnFnE/EPj/XCXV LJ5jVKIy/gi9vHV7jF7ObG1jqVk70CurD5F9+q6BVRnOXBcTSzKffqcamn6nH/NCmmVp sLnGnOeZhZOEoFeGaCsjViH8D2neMDnjlljbmbHchuYku3XPaIkPMTMyNR+pc+uaICca M3hA== MIME-Version: 1.0 X-Received: by 10.66.142.233 with SMTP id rz9mr16978874pab.71.1396642640018; Fri, 04 Apr 2014 13:17:20 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Fri, 4 Apr 2014 13:17:19 -0700 (PDT) In-Reply-To: <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> Date: Fri, 4 Apr 2014 13:17:19 -0700 Message-ID: From: Oleg Moskalenko To: "Gonzalo Salgueiro (gsalguei)" Content-Type: multipart/alternative; boundary=001a113448086fc4fa04f63d3492 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/LZZKEYwFlpHGHT946MILKH13y9o Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:17:28 -0000 --001a113448086fc4fa04f63d3492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If ALPN is really independent of DTLS, I see no reason why they have to be combined in the draft document that was created solely for the DTLS feature introduction for STUNl. On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) < gsalguei@cisco.com> wrote: > > On Apr 4, 2014, at 2:00 PM, Simon Perreault > wrote: > > > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit : > >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't > seem it should be buried in STUNoDTLS. Shall we produce a dedicated draf= t > for this? > > > > My preference would be for "buried in STUNoDTLS". :) But I'm open to > arguments for a dedicated draft. > > My position is that the ALPN reg is entirely independent of STUNoDTLS, > which is why we considered more contextually relevant for the broader > STUNbis effort. A standalone dedicated ALPN reg doc to point to seems > cleaner to me, but I'm open to WG decision on this. > > -G > > > > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113448086fc4fa04f63d3492 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If ALPN is really independent of DTLS, I see no reason why= they have to be combined in the draft document that was created solely for= the DTLS feature introduction for STUNl.


On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo= Salgueiro (gsalguei) <gsalguei@cisco.com> wrote:

On Apr 4, 2014, at 2:00 PM, Simon Perreault <simon.perreault@viagenie.ca> wrote:

> Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit :
>> Understood. =A0Nonetheless, even if not a part of STUNbis, it does= n't seem it should be buried in STUNoDTLS. =A0Shall we produce a dedica= ted draft for this?
>
> My preference would be for "buried in STUNoDTLS". :) But I&#= 39;m open to arguments for a dedicated draft.

My position is that the ALPN reg is entirely independent of STUNoDTLS= , which is why we considered more contextually relevant for the broader STU= Nbis effort. =A0A standalone dedicated ALPN reg doc to point to seems clean= er to me, but I'm open to WG decision on this.

-G

>
> Simon

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

--001a113448086fc4fa04f63d3492-- From nobody Fri Apr 4 14:21:07 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10C41A01B4 for ; Fri, 4 Apr 2014 14:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 cYYqAP4INXAe for ; Fri, 4 Apr 2014 14:20:59 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 44DE11A019B for ; Fri, 4 Apr 2014 14:20:59 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6353D4749C for ; Fri, 4 Apr 2014 21:20:54 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4BF6747428 for ; Fri, 4 Apr 2014 21:20:54 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 2302380044 for ; Fri, 4 Apr 2014 21:20:54 +0000 (GMT) Message-ID: <533F2234.4060402@akamai.com> Date: Fri, 04 Apr 2014 17:20:52 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140331214024.15420.9235.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/0Sls7seDoGg2Q4-6dH_6lHUoF6s Subject: Re: [tram] Fwd: I-D Action: draft-johnston-tram-stun-origin-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 21:21:04 -0000 Hi Alan, Has attribute number 0x802F been assigned? I don't see it in the official registry. If not, then I suggest you follow the common practice of using a placeholder (e.g. TBD) in place of the option number throughout the document with a note to the editor about the search-and-replace operation to be done before publishing. I know there's a related editor's note in the document, but the referenced rfc4020 specifically indicates that you should not include an unallocated value in an I.D. On a separate note, RFC5389 requires a maximum message size of 548 bytes when the sender is using IPv4 and the MTU is not known. Even for cases where the MTU is known, we frequently see mobile clients with very small MTUs at or close to the IPv4 minimum, which would require this small message size even after MTU discovery. I'm concerned about an attribute with a max value size that uses up nearly 50% of that space. I think it would be good for the draft to discuss this issue and provide some related guidance on usage. For example, how much of the 548 bytes are used in a typical STUN Bind request? or a TURN Allocate request? Does use of this attribute conflict with similar size constraints imposed by any other current drafts? If there isn't enough space, how should the client handle it? In addition to that, I would appreciate a bit more detail about where this option is expected to show up in the message exchanges. I think I know, but I'm not sure. Am I correct that you expect its use for authentication to only require it in the initial unauthenticated TURN Allocate request? And that any later use would be primarily for diagnostics? If that's the case, then it might be worth pointing this out in the Security Considerations section (i.e. that the primary security related use is the one case where auth doesn't apply). --Brandon On 03/31/2014 05:41 PM, Alan Johnston wrote: > All, > > We have revised the STUN Origin draft based on feedback on the list and > from London. > > Comments most welcome. > > - Alan - > > ---------- Forwarded message ---------- > From: ** > > Date: Mon, Mar 31, 2014 at 4:40 PM > Subject: I-D Action: draft-johnston-tram-stun-origin-02.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : An Origin Attribute for the STUN Protocol > Authors : Alan Johnston > Justin Uberti > John Yoakum > Kundan Singh > Filename : draft-johnston-tram-stun-origin-02.txt > Pages : 10 > Date : 2014-03-31 > > Abstract: > STUN, or Session Traversal Utilities for NAT, is a protocol used to > assist other protocols traverse Network Address Translators or NATs. > STUN, and STUN extensions such as TURN, or Traversal Using Relays > around NAT, and ICE, Interactive Communications Establishment, have > been around for many years but with WebRTC, Web Real-Time > Communications, STUN and related extensions are about to see major > deployments and implementation due to these protocols being > implemented in browsers. This specification defines an ORIGIN > attribute for STUN that can be used in similar ways to the HTTP > header field of the same name. WebRTC browsers utilizing STUN and > TURN would include this attribute which would provide servers with > additional information about the STUN and TURN requests they receive. > This specification defines the usage of the STUN ORIGIN attribute for > web and SIP contexts. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org > . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft Internet-Draft> directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Apr 4 16:03:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6A61A02A4 for ; Fri, 4 Apr 2014 16:03:14 -0700 (PDT) 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 65FFCKRnrlBX for ; Fri, 4 Apr 2014 16:03:10 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BA9DB1A0295 for ; Fri, 4 Apr 2014 16:03:09 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id lj1so4109234pab.20 for ; Fri, 04 Apr 2014 16:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/1YvMozPmzjbiWjX9giOab9bJJcJgvJgdb2VDBYrbiI=; b=H83QXVafusi1vUw1AwCGE9wosoKW8Ag6g/epvnFIi5h75xLLS+KMDDn2HZKyNQf8mB DKtZo/L9p1OS51hsggbFj10T1BuTpHhU5s6m2z8vL2GZwz+oi9qpjfHKlKR3YC1SFhzV K9HBCk5dFmLa5fh9bcsWubBnaA07Cwii0l6Qb4FEO9NrQ6FQdjwIJeDWvLYKXSJDTzDH uNU5n8FbJKpInhfCILl/u/23AokwCW15Rtxn9pUTWKJ8WYpqjG3tpel/y4cYBawStrxO MGI63oaRxFaBTOwc08lc0VWbMmPM29eSos4oiwAhqGGWKcMigh0l8e0jcV5Jen8mG7z2 Q4xg== X-Received: by 10.66.139.70 with SMTP id qw6mr17350598pab.111.1396652585196; Fri, 04 Apr 2014 16:03:05 -0700 (PDT) Received: from dhcpx-192-120.corp.yahoo.com (nat-dip27-wl-a.cfw-a-gci.corp.yahoo.com. [66.228.162.32]) by mx.google.com with ESMTPSA id cz3sm20209499pbc.9.2014.04.04.16.03.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Apr 2014 16:03:04 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Oleg Moskalenko In-Reply-To: <533F2234.4060402@akamai.com> Date: Fri, 4 Apr 2014 16:03:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140331214024.15420.9235.idtracker@ietfa.amsl.com> <533F2234.4060402@akamai.com> To: Brandon Williams X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/tram/W0wPOkr53MBuz6uKIDX-Y_Zxi6Y Cc: tram@ietf.org Subject: Re: [tram] I-D Action: draft-johnston-tram-stun-origin-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 23:03:14 -0000 On Apr 4, 2014, at 2:20 PM, Brandon Williams = wrote: >=20 > In addition to that, I would appreciate a bit more detail about where = this option is expected to show up in the message exchanges. I think I = know, but I'm not sure. Am I correct that you expect its use for = authentication to only require it in the initial unauthenticated TURN = Allocate request? And that any later use would be primarily for = diagnostics? I guess that=92s true, this is how it was discussed. Oleg From nobody Fri Apr 4 17:05:35 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD051A0367 for ; Fri, 4 Apr 2014 17:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AQ_oeS3ymLIn for ; Fri, 4 Apr 2014 17:05:30 -0700 (PDT) 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 E61CF1A0361 for ; Fri, 4 Apr 2014 17:05:29 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id im17so3685771vcb.37 for ; Fri, 04 Apr 2014 17:05:25 -0700 (PDT) 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=LKa8cM8TSOhuiT0VW8zrJpCSEROs47zFEj8qpDutZ2E=; b=YTQM7sLX7Sk/71uMMWEmlMLv53EHrWWUibhmuAypqGtGd/3AdezvxVDiKhbPrlpCnC aSVB+1K5Wul6cgcEr3E0BVYo9CcDuthA0V5QJFu51+6mFTla7SkkPiMR0g5gxp+OZnM8 VY5If1jUssVh5R8uIjN9Y+HHOzRICxMTsmrTwLh/dl2GzEgxst8o7316bo9ebpTditEY Key0YOmoqTFfcqkt1OWe1nBW0x9OLOFLl7k3trsd+D6mtIL7MmPJyv8EtXg11A4BdwZw v+yAEEJbQg1yumtYXznyL/JiKKJ/q9qBBqDk4e+OVabbWYw85RokomoSqIgjCWz0NkmZ ejiQ== 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=LKa8cM8TSOhuiT0VW8zrJpCSEROs47zFEj8qpDutZ2E=; b=IGu+KWaDtifpLajw2ybO9s/FIzb1kdyPzegX0UkB3LJRodd05DRdOYExpRmCLqGNdQ wtcwKCLg8MKbMAM1sQ9f6a9OFn6LOjidUf7HXzgnJo+LpPa2FJzsQYdGPyIwNyo0k6pb E7IQd0xuNO65ZWtqvqIc4iXviKCkc8b5MP1vJ4mlTcdhWHeGzApVPGxex0NyWbQ2aWbt 8USzXe8csK68z53W8VrnjDS8pElP9o8B8ulfhfj8npLyXAOkDAPQbfF3kXhZAiQGmtrI pvx+5LoiAdtHQ/RN96sG2b/hpbj9dxm1o5ULa131xJE7bk3NzAZkqNWDyHhcfB+P3g6s 4X5w== X-Gm-Message-State: ALoCoQlmCQf3WkOEa1ayl+jkfY2z7etn6qqPxzmBR4+BEWhUcN0u7BFrXckVOt9Rl5j+rPBpk2kli5REDLPiI0lHXdFVM957CWmp+94RGNROr9L80K2OjKPyMg6Ca+NR6LMqajnjyd7C5sm5a4rAbU498Pt8vc+Z/h93vAe2vqTluMHAYZ/GBK58+AuaUKndgzNQmmIjFt5x X-Received: by 10.58.220.161 with SMTP id px1mr7690790vec.13.1396656324897; Fri, 04 Apr 2014 17:05:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.229.73 with HTTP; Fri, 4 Apr 2014 17:05:04 -0700 (PDT) In-Reply-To: <533F2234.4060402@akamai.com> References: <20140331214024.15420.9235.idtracker@ietfa.amsl.com> <533F2234.4060402@akamai.com> From: Justin Uberti Date: Fri, 4 Apr 2014 17:05:04 -0700 Message-ID: To: Brandon Williams Content-Type: multipart/alternative; boundary=047d7bdc9e021e8c7b04f6406488 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ac9hkyBPSkeNrlSb5Ns-P3R91cw Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-johnston-tram-stun-origin-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 00:05:34 -0000 --047d7bdc9e021e8c7b04f6406488 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 4, 2014 at 2:20 PM, Brandon Williams < brandon.williams@akamai.com> wrote: > Hi Alan, > > Has attribute number 0x802F been assigned? I don't see it in the official > registry. If not, then I suggest you follow the common practice of using a > placeholder (e.g. TBD) in place of the option number throughout the > document with a note to the editor about the search-and-replace operation > to be done before publishing. I know there's a related editor's note in the > document, but the referenced rfc4020 specifically indicates that you should > not include an unallocated value in an I.D. > > On a separate note, RFC5389 requires a maximum message size of 548 bytes > when the sender is using IPv4 and the MTU is not known. Even for cases > where the MTU is known, we frequently see mobile clients with very small > MTUs at or close to the IPv4 minimum, This question has come up in the past and the consensus (and empirical data from Chrome) indicated that nowadays MTUs < 1280 are quite uncommon. Can you provide some more detailed stats and examples? > which would require this small message size even after MTU discovery. I'm > concerned about an attribute with a max value size that uses up nearly 50% > of that space. I think it would be good for the draft to discuss this issue > and provide some related guidance on usage. For example, how much of the > 548 bytes are used in a typical STUN Bind request? or a TURN Allocate > request? Does use of this attribute conflict with similar size constraints > imposed by any other current drafts? If there isn't enough space, how > should the client handle it? > > In addition to that, I would appreciate a bit more detail about where this > option is expected to show up in the message exchanges. I think I know, but > I'm not sure. Am I correct that you expect its use for authentication to > only require it in the initial unauthenticated TURN Allocate request? And > that any later use would be primarily for diagnostics? If that's the case, > then it might be worth pointing this out in the Security Considerations > section (i.e. that the primary security related use is the one case where > auth doesn't apply). > > --Brandon > > > On 03/31/2014 05:41 PM, Alan Johnston wrote: > >> All, >> >> We have revised the STUN Origin draft based on feedback on the list and >> from London. >> >> Comments most welcome. >> >> - Alan - >> >> ---------- Forwarded message ---------- >> From: ** > >> Date: Mon, Mar 31, 2014 at 4:40 PM >> Subject: I-D Action: draft-johnston-tram-stun-origin-02.txt >> To: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : An Origin Attribute for the STUN Protocol >> Authors : Alan Johnston >> Justin Uberti >> John Yoakum >> Kundan Singh >> Filename : draft-johnston-tram-stun-origin-02.txt >> Pages : 10 >> Date : 2014-03-31 >> >> Abstract: >> STUN, or Session Traversal Utilities for NAT, is a protocol used to >> assist other protocols traverse Network Address Translators or NATs. >> STUN, and STUN extensions such as TURN, or Traversal Using Relays >> around NAT, and ICE, Interactive Communications Establishment, have >> been around for many years but with WebRTC, Web Real-Time >> Communications, STUN and related extensions are about to see major >> deployments and implementation due to these protocols being >> implemented in browsers. This specification defines an ORIGIN >> attribute for STUN that can be used in similar ways to the HTTP >> header field of the same name. WebRTC browsers utilizing STUN and >> TURN would include this attribute which would provide servers with >> additional information about the STUN and TURN requests they receive. >> This specification defines the usage of the STUN ORIGIN attribute for >> web and SIP contexts. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft > >> Internet-Draft> directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7bdc9e021e8c7b04f6406488 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 4, 2014 at 2:20 PM, Brandon Williams = <brando= n.williams@akamai.com> wrote:
Hi Alan,

Has attribute number 0x802F been assigned? I don't see it in the offici= al registry. If not, then I suggest you follow the common practice of using= a placeholder (e.g. TBD) in place of the option number throughout the docu= ment with a note to the editor about the search-and-replace operation to be= done before publishing. I know there's a related editor's note in = the document, but the referenced rfc4020 specifically indicates that you sh= ould not include an unallocated value in an I.D.

On a separate note, RFC5389 requires a maximum message size of 548 bytes wh= en the sender is using IPv4 and the MTU is not known. Even for cases where = the MTU is known, we frequently see mobile clients with very small MTUs at = or close to the IPv4 minimum,

This question has come up in the past and the consensus= (and empirical data from Chrome) indicated that nowadays MTUs < 1280 ar= e quite uncommon. Can you provide some more detailed stats and examples?

=C2=A0
which would requ= ire this small message size even after MTU discovery. I'm concerned abo= ut an attribute with a max value size that uses up nearly 50% of that space= . I think it would be good for the draft to discuss this issue and provide = some related guidance on usage. For example, how much of the 548 bytes are = used in a typical STUN Bind request? or a TURN Allocate request? Does use o= f this attribute conflict with similar size constraints imposed by any othe= r current drafts? If there isn't enough space, how should the client ha= ndle it?

In addition to that, I would appreciate a bit more detail about where this = option is expected to show up in the message exchanges. I think I know, but= I'm not sure. Am I correct that you expect its use for authentication = to only require it in the initial unauthenticated TURN Allocate request? An= d that any later use would be primarily for diagnostics? If that's the = case, then it might be worth pointing this out in the Security Consideratio= ns section (i.e. that the primary security related use is the one case wher= e auth doesn't apply).

--Brandon


On 03/31/2014 05:41 PM, Alan Johnston wrote:
All,

We have revised the STUN Origin draft based on feedback on the list and
from London.

Comments most welcome.

- Alan -

---------- Forwarded message ----------
From: ** <= internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
Date: Mon, Mar 31, 2014 at 4:40 PM
Subject: I-D Action: draft-johnston-tram-stun-origin-02.txt
To: i-d-announce= @ietf.org <mailto:i-d-announce@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts
directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : An Origin Attribute for the STUN Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Ala= n Johnston
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Justin Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0John Yoakum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Kundan Singh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: dra= ft-johnston-tram-stun-origin-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: 2014-03-31

Abstract:
=C2=A0 =C2=A0 STUN, or Session Traversal Utilities for NAT, is a protocol u= sed to
=C2=A0 =C2=A0 assist other protocols traverse Network Address Translators o= r NATs.
=C2=A0 =C2=A0 STUN, and STUN extensions such as TURN, or Traversal Using Re= lays
=C2=A0 =C2=A0 around NAT, and ICE, Interactive Communications Establishment= , have
=C2=A0 =C2=A0 been around for many years but with WebRTC, Web Real-Time
=C2=A0 =C2=A0 Communications, STUN and related extensions are about to see = major
=C2=A0 =C2=A0 deployments and implementation due to these protocols being =C2=A0 =C2=A0 implemented in browsers. =C2=A0This specification defines an = ORIGIN
=C2=A0 =C2=A0 attribute for STUN that can be used in similar ways to the HT= TP
=C2=A0 =C2=A0 header field of the same name. =C2=A0WebRTC browsers utilizin= g STUN and
=C2=A0 =C2=A0 TURN would include this attribute which would provide servers= with
=C2=A0 =C2=A0 additional information about the STUN and TURN requests they = receive.
=C2=A0 =C2=A0 This specification defines the usage of the STUN ORIGIN attri= bute for
=C2=A0 =C2=A0 web and SIP contexts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-johnston= -tram-stun-origin/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-johnston-tram-stun= -origin-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-jo= hnston-tram-stun-origin-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org
<http://tools.ietf.o= rg>.


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announ= ce@ietf.org <mailto:I-D-Announce@ietf.org>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft <https://www.ietf.org/mailman/listinfo/i-d-a= nnounce

--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

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

--047d7bdc9e021e8c7b04f6406488-- From nobody Sun Apr 6 16:03:22 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333A11A0515 for ; Sun, 6 Apr 2014 16:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 fSI-lGjTCvBQ for ; Sun, 6 Apr 2014 16:03:16 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 13E541A014F for ; Sun, 6 Apr 2014 16:03:16 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 78EB8475AD for ; Sun, 6 Apr 2014 23:03:10 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 50D9F47440 for ; Sun, 6 Apr 2014 23:03:10 +0000 (GMT) Received: from [172.28.13.73] (bowill.kendall.corp.akamai.com [172.28.13.73]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 1F3C02029 for ; Sun, 6 Apr 2014 23:03:10 +0000 (GMT) Message-ID: <5341DD2D.8040103@akamai.com> Date: Sun, 06 Apr 2014 19:03:09 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140331214024.15420.9235.idtracker@ietfa.amsl.com> <533F2234.4060402@akamai.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RCJzlqSZ2Q4nSOZU0jvP1tEdPgI Subject: Re: [tram] Fwd: I-D Action: draft-johnston-tram-stun-origin-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 23:03:20 -0000 Hi Justin, Let me backtrack on my use of the word "frequently", which suggests that small MTUs are more common than I believe them to be. Let me say instead that small MTUs are not unheard of. I am unfortunately not in a position to give numbers, because we no longer forward the DF bit on outgoing packets (for this reason). I agree that it is uncommon, but when it occurs, it can cause session failure if you don't help the packets get through. So, despite my poor choice of words, I really just meant to indicate that it does happen sometimes, and that it would be good for a spec that allows such a large attribute value to provide some guidance on how to handle the attribute if the resulting message will violate the message size constraints required by the existing RFCs. --Brandon PS: I will do some more investigation and see if I can come up with a number after all, though I'm not too confident. On 04/04/2014 08:05 PM, Justin Uberti wrote: > > > > On Fri, Apr 4, 2014 at 2:20 PM, Brandon Williams > > wrote: > > Hi Alan, > > Has attribute number 0x802F been assigned? I don't see it in the > official registry. If not, then I suggest you follow the common > practice of using a placeholder (e.g. TBD) in place of the option > number throughout the document with a note to the editor about the > search-and-replace operation to be done before publishing. I know > there's a related editor's note in the document, but the referenced > rfc4020 specifically indicates that you should not include an > unallocated value in an I.D. > > On a separate note, RFC5389 requires a maximum message size of 548 > bytes when the sender is using IPv4 and the MTU is not known. Even > for cases where the MTU is known, we frequently see mobile clients > with very small MTUs at or close to the IPv4 minimum, > > > This question has come up in the past and the consensus (and empirical > data from Chrome) indicated that nowadays MTUs < 1280 are quite > uncommon. Can you provide some more detailed stats and examples? > > which would require this small message size even after MTU > discovery. I'm concerned about an attribute with a max value size > that uses up nearly 50% of that space. I think it would be good for > the draft to discuss this issue and provide some related guidance on > usage. For example, how much of the 548 bytes are used in a typical > STUN Bind request? or a TURN Allocate request? Does use of this > attribute conflict with similar size constraints imposed by any > other current drafts? If there isn't enough space, how should the > client handle it? > > In addition to that, I would appreciate a bit more detail about > where this option is expected to show up in the message exchanges. I > think I know, but I'm not sure. Am I correct that you expect its use > for authentication to only require it in the initial unauthenticated > TURN Allocate request? And that any later use would be primarily for > diagnostics? If that's the case, then it might be worth pointing > this out in the Security Considerations section (i.e. that the > primary security related use is the one case where auth doesn't apply). > > --Brandon > > > On 03/31/2014 05:41 PM, Alan Johnston wrote: > > All, > > We have revised the STUN Origin draft based on feedback on the > list and > from London. > > Comments most welcome. > > - Alan - > > ---------- Forwarded message ---------- > From: ** > >> > Date: Mon, Mar 31, 2014 at 4:40 PM > Subject: I-D Action: draft-johnston-tram-stun-__origin-02.txt > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : An Origin Attribute for the STUN > Protocol > Authors : Alan Johnston > Justin Uberti > John Yoakum > Kundan Singh > Filename : draft-johnston-tram-stun-__origin-02.txt > Pages : 10 > Date : 2014-03-31 > > Abstract: > STUN, or Session Traversal Utilities for NAT, is a protocol > used to > assist other protocols traverse Network Address Translators > or NATs. > STUN, and STUN extensions such as TURN, or Traversal Using > Relays > around NAT, and ICE, Interactive Communications > Establishment, have > been around for many years but with WebRTC, Web Real-Time > Communications, STUN and related extensions are about to > see major > deployments and implementation due to these protocols being > implemented in browsers. This specification defines an ORIGIN > attribute for STUN that can be used in similar ways to the HTTP > header field of the same name. WebRTC browsers utilizing > STUN and > TURN would include this attribute which would provide > servers with > additional information about the STUN and TURN requests > they receive. > This specification defines the usage of the STUN ORIGIN > attribute for > web and SIP contexts. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/__doc/draft-johnston-tram-stun-__origin/ > > > There's also a htmlized version available at: > http://tools.ietf.org/html/__draft-johnston-tram-stun-__origin-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?__url2=draft-johnston-tram-stun-__origin-02 > > > > Please note that it may take a couple of minutes from the time > of submission > until the htmlized version and diff are available at > tools.ietf.org > . > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-__drafts/ > > > _________________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/__listinfo/i-d-announce > > Internet-Draft > > > Internet-Draft> directories: http://www.ietf.org/shadow.__html > > or ftp://ftp.ietf.org/ietf/__1shadow-sites.txt > > > > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > _________________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/__listinfo/tram > > > From nobody Mon Apr 7 06:55:37 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAA01A0708 for ; Mon, 7 Apr 2014 06:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 32cgDS6h0B7H for ; Mon, 7 Apr 2014 06:55:30 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 59D941A0429 for ; Mon, 7 Apr 2014 06:55:30 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:7c8a:ed66:4a94:8b19]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9B0E0403C2 for ; Mon, 7 Apr 2014 09:55:24 -0400 (EDT) Message-ID: <5342AE4C.10400@viagenie.ca> Date: Mon, 07 Apr 2014 09:55:24 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140404165719.31339.3827.idtracker@ietfa.amsl.com> <533EE4F7.1020701@akamai.com> <533EED5A.1020409@viagenie.ca> <533F0886.4020201@akamai.com> In-Reply-To: <533F0886.4020201@akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/0J8dFw2WG-tiJaSJuxVjmnwYug0 Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 13:55:36 -0000 Le 2014-04-04 15:31, Brandon Williams a écrit : > re: CHECK-ALTERNATE > CHECK-ALTERNATE serves two purposes: backward compatibility and client > flexibility. The client flexibility goal is spelled out in the > introduction, though I can see that the relationship between that > statement and the definition of the attribute isn't clearly stated. Assuming you're referring to this part: The client application indicates the nature of the desired response, which allows the client to treat the alternate server selection as either a requirement or a suggestion. This flexibility gives the client the option to choose the best way for the Interactive Connectivity Establishment (ICE) protocol [RFC5245] to respond (e.g. discarding the existing relay candidate for communication with this peer versus evaluating the two candidate servers using ICE connectivity checks and selecting the best one). Why does the client need this flexibility? What kind of external stimulus would cause the client to behave one way or the other? > i see now that the backward compatibility (prevent transmission of the > ALTERNATE-SERVER attribute to a client that doesn't support this use) > isn't stated anywhere. I'll be sure to clarify those points in the next > revision. Right, the ALTERNATE-SERVER mechanism as defined in RFC 5389 is optional. The problem is that there is no way for the server to know whether the client implements it or not. I see the need for capability signalling. > re: XOR-OTHER-ADDRESS > In a case where both clients to use TURN servers, you want them to > converge as quickly as possible on the pair that will provide the best > performance. Typically, the system will attempt to get them to use the > same relay server. If each one picks the TURN server that is best based > on its peer's relay address but the relay server was a bad pick in the > first place, then you'll frequently end up with a bad alternate and > never converge on a good pair. I think it requires a more complicated > example than the one in the introduction to really spell this out. > > Consider this case (T == TURN relay; P == peer): > > T1 <-- P1 T2 P2 --> T3 > > If T1, T2, and T3 are all part of the same system and P2 asks T3 for an > alternate server to get to T1, the system will most likely send it to T1 > in order to avoid unnecessary relay hops. Likewise, if P1 asks T1 for an > alternate to T3, it will get T3. They would get a more optimal > end-to-end connection, but not the best end-to-end connection, since in > this case, you want them to converge on T2. > > I think you could probably get to the same decision using the combined > set of responses for both the server-reflexive candidate and the relayed > candidate, but I think that the addition of this attribute can help the > system to get you there faster. > > Do you have thoughts on this rationale? If it seems reasonable, then > I'll add some detail about it to the next revision. Well, in this particular example: - I understand why having both TURN sessions terminate on the same server is optimal. - I don't see how T2 is better than T1 or T3, assuming that T1 (resp. T3) is "close" to P1 (resp. P3). As long as triangle routing is avoided, it doesn't really matter that the TURN server be halfway between the two. As long as it is close to the best path between P1 and P2, it's optimal. Is that understanding correct? So my thinking is that since all TURN servers are under the same administrative entity, we can expect that each server knows about the others' IP addresses, and can redirect intelligently on a CreatePermission or ChannelBind request containing one of the TURN servers' IP address in the XOR-PEER-ADDRESS attribute. That is, it would redirect the client to the peer's TURN server so that both TURN sessions are terminated on the same server. So I don't see a need for XOR-OTHER-ADDRESS in this case either. 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 nobody Mon Apr 7 07:00:21 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A102D1A0713 for ; Mon, 7 Apr 2014 07:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Co46vLGTrdOZ for ; Mon, 7 Apr 2014 07:00:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C7B211A0708 for ; Mon, 7 Apr 2014 07:00:13 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:7c8a:ed66:4a94:8b19]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 135D941163 for ; Mon, 7 Apr 2014 10:00:08 -0400 (EDT) Message-ID: <5342AF67.8020306@viagenie.ca> Date: Mon, 07 Apr 2014 10:00:07 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140331214024.15420.9235.idtracker@ietfa.amsl.com> <533F2234.4060402@akamai.com> In-Reply-To: <533F2234.4060402@akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BNTqCH_p-zWS2IIGK_etAqulblc Subject: Re: [tram] Fwd: I-D Action: draft-johnston-tram-stun-origin-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:00:19 -0000 Le 2014-04-04 17:20, Brandon Williams a écrit : > Has attribute number 0x802F been assigned? I don't see it in the > official registry. If not, then I suggest you follow the common practice > of using a placeholder (e.g. TBD) in place of the option number > throughout the document with a note to the editor about the > search-and-replace operation to be done before publishing. I know > there's a related editor's note in the document, but the referenced > rfc4020 specifically indicates that you should not include an > unallocated value in an I.D. +1 This is more important than it may seem. 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 nobody Mon Apr 7 07:18:10 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCB11A0452 for ; Mon, 7 Apr 2014 07:18:08 -0700 (PDT) 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 IQOfq3eHwSEy for ; Mon, 7 Apr 2014 07:18:02 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D2F571A0782 for ; Mon, 7 Apr 2014 07:17:58 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id q5so5162102wiv.16 for ; Mon, 07 Apr 2014 07:17:52 -0700 (PDT) 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=SBUJ5Ve6JajuyMVtyPX+JN7UYYG7lwj1q8STCH+/UyU=; b=In8/8b3RoYmCEh4IOMIF6l6DR/2xhxOVUh9LKNEc0YWtkWi0My9E2u34zUDc+h5Pu7 wKRX1ndu75VHu0cC/ci/9EzoJXpL8xy2YWohLhj1xqUeVmE9oNiCpNSxZs4J6cvyYPxP X1YpnloEkIlLbhnbPtepiObIS2YuEj6/WHDJAWwbNXKaVbUkufIaEKcIwx3DOXiblwbu v2v93E71CjpiAL0YPMWxeObKN1sCiF6vF4jSaipQFkJR/FnOXBoEeiuEzyVWPFNIuQE6 zW/4X/agu1N5B5H1w1RVj3qnMqHoSIqPIVNzEjevbJJ+iD3SQNRED0D9CYjhYbz8g7kK QpWA== MIME-Version: 1.0 X-Received: by 10.180.106.167 with SMTP id gv7mr26138455wib.40.1396880268138; Mon, 07 Apr 2014 07:17:48 -0700 (PDT) Received: by 10.217.152.10 with HTTP; Mon, 7 Apr 2014 07:17:48 -0700 (PDT) In-Reply-To: <5342AF67.8020306@viagenie.ca> References: <20140331214024.15420.9235.idtracker@ietfa.amsl.com> <533F2234.4060402@akamai.com> <5342AF67.8020306@viagenie.ca> Date: Mon, 7 Apr 2014 09:17:48 -0500 Message-ID: From: Alan Johnston To: Simon Perreault Content-Type: multipart/alternative; boundary=e89a8f2357292d3e6e04f674882c Archived-At: http://mailarchive.ietf.org/arch/msg/tram/kASB2JWQrkM7ok52Ztr5pTvPszk Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-johnston-tram-stun-origin-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:18:08 -0000 --e89a8f2357292d3e6e04f674882c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As we say in the draft, if it is adopted as a WG item, we will do whatever the chairs think is best. I suspect we could finish the draft in the same amount of time as an RFC 4020 action. I would also point out that we did use a TBD value in the first version of the draft to make sure that that was interest. We put in the value in the next revision after we had interest in having running code. - Alan - On Mon, Apr 7, 2014 at 9:00 AM, Simon Perreault wrote: > Le 2014-04-04 17:20, Brandon Williams a =E9crit : > > Has attribute number 0x802F been assigned? I don't see it in the > > official registry. If not, then I suggest you follow the common practic= e > > of using a placeholder (e.g. TBD) in place of the option number > > throughout the document with a note to the editor about the > > search-and-replace operation to be done before publishing. I know > > there's a related editor's note in the document, but the referenced > > rfc4020 specifically indicates that you should not include an > > unallocated value in an I.D. > > +1 > > This is more important than it may seem. > > 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 > --e89a8f2357292d3e6e04f674882c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As we say in the draft, if it is adopted as a WG item, we = will do whatever the chairs think is best. =A0I suspect we could finish the= draft in the same amount of time as an RFC 4020 action. =A0

=
I would also point out that we did use a TBD value in the first version of = the draft to make sure that that was interest. =A0We put in the value in th= e next revision after we had interest in having running code.
- Alan -=A0


On Mon, Apr 7, 2014 at 9:00 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2014-04-04 17:20, Brandon Williams a =E9c= rit :
> Has attribute number 0x802F been assigned? I don't see it in the > official registry. If not, then I suggest you follow the common practi= ce
> of using a placeholder (e.g. TBD) in place of the option number
> throughout the document with a note to the editor about the
> search-and-replace operation to be done before publishing. I know
> there's a related editor's note in the document, but the refer= enced
> rfc4020 specifically indicates that you should not include an
> unallocated value in an I.D.

+1

This is more important than it may seem.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

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

--e89a8f2357292d3e6e04f674882c-- From nobody Mon Apr 7 07:49:07 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25CD1A045A for ; Mon, 7 Apr 2014 07:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Ji1yXrmegdLx for ; Mon, 7 Apr 2014 07:48:57 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id D6E9E1A0785 for ; Mon, 7 Apr 2014 07:48:52 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 33FA9285E1 for ; Mon, 7 Apr 2014 14:48:47 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 10B4C284DA for ; Mon, 7 Apr 2014 14:48:47 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id C77E980051 for ; Mon, 7 Apr 2014 14:48:46 +0000 (GMT) Message-ID: <5342BACB.3050303@akamai.com> Date: Mon, 07 Apr 2014 10:48:43 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140404165719.31339.3827.idtracker@ietfa.amsl.com> <533EE4F7.1020701@akamai.com> <533EED5A.1020409@viagenie.ca> <533F0886.4020201@akamai.com> <5342AE4C.10400@viagenie.ca> In-Reply-To: <5342AE4C.10400@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bykB8LIPY9XoXfCcVZDPlByvjJg Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:49:02 -0000 > Why does the client need this flexibility? What kind of external > stimulus would cause the client to behave one way or the other? I see two different primary criteria: session establishment time vs simplicity. If you want to optimize for faster session establishment, then you would want to receive a "hint" that tells you where you will get better service. This allows you to continue using the existing-but-suboptimal allocation/binding while you are setting up the new allocation/binding. This potentially has greater associated internal complexity, since you've got to maintain multiple active associated sessions for the peer pairing and figure out when it's OK to switch over. If you want to optimize for internal simplicity, then you probably just want to get an error response and deal with the associated offer updates, etc. There's only one activity to manage for the peer pairing at any particular point in time. You risk taking a bit longer for session establishment, but that might be a reasonable trade-off. The choice also has something to do with the application provider's relationship to the relay provider, I think. A higher trust relationship on the performance side could lead the application provider to desire the simplicity of just switching over to another allocation/binding as quickly as possible. A lower trust relationship (I know you think this relay is better, but I want to check that myself) could lead the application provider to want to run tests and make an internal decision about which one to use. > - I don't see how T2 is better than T1 or T3, assuming that T1 (resp. > T3) is "close" to P1 (resp. P3). As long as triangle routing is avoided, > it doesn't really matter that the TURN server be halfway between the > two. As long as it is close to the best path between P1 and P2, it's > optimal. Is that understanding correct? > > So my thinking is that since all TURN servers are under the same > administrative entity, we can expect that each server knows about the > others' IP addresses, and can redirect intelligently on a > CreatePermission or ChannelBind request containing one of the TURN > servers' IP address in the XOR-PEER-ADDRESS attribute. That is, it would > redirect the client to the peer's TURN server so that both TURN sessions > are terminated on the same server. So I don't see a need for > XOR-OTHER-ADDRESS in this case either. You're right that as long as the relay server for at least one of the peers is very close to the peer itself, then that relay server will end up being the best candidate (or at least a very good one). However, if both of the current relay servers would end up resulting in triangle routing, it's important to be able to figure that out, which requires that you know both relay addresses and both peer addresses. --Brandon On 04/07/2014 09:55 AM, Simon Perreault wrote: > Le 2014-04-04 15:31, Brandon Williams a écrit : >> re: CHECK-ALTERNATE >> CHECK-ALTERNATE serves two purposes: backward compatibility and client >> flexibility. The client flexibility goal is spelled out in the >> introduction, though I can see that the relationship between that >> statement and the definition of the attribute isn't clearly stated. > > Assuming you're referring to this part: > > The client application indicates the nature of the desired > response, which allows the client to treat the alternate server > selection as either a requirement or a suggestion. This flexibility > gives the client the option to choose the best way for the > Interactive Connectivity Establishment (ICE) protocol [RFC5245] to > respond (e.g. discarding the existing relay candidate for > communication with this peer versus evaluating the two candidate > servers using ICE connectivity checks and selecting the best one). > > Why does the client need this flexibility? What kind of external > stimulus would cause the client to behave one way or the other? > >> i see now that the backward compatibility (prevent transmission of the >> ALTERNATE-SERVER attribute to a client that doesn't support this use) >> isn't stated anywhere. I'll be sure to clarify those points in the next >> revision. > > Right, the ALTERNATE-SERVER mechanism as defined in RFC 5389 is > optional. The problem is that there is no way for the server to know > whether the client implements it or not. I see the need for capability > signalling. > >> re: XOR-OTHER-ADDRESS >> In a case where both clients to use TURN servers, you want them to >> converge as quickly as possible on the pair that will provide the best >> performance. Typically, the system will attempt to get them to use the >> same relay server. If each one picks the TURN server that is best based >> on its peer's relay address but the relay server was a bad pick in the >> first place, then you'll frequently end up with a bad alternate and >> never converge on a good pair. I think it requires a more complicated >> example than the one in the introduction to really spell this out. >> >> Consider this case (T == TURN relay; P == peer): >> >> T1 <-- P1 T2 P2 --> T3 >> >> If T1, T2, and T3 are all part of the same system and P2 asks T3 for an >> alternate server to get to T1, the system will most likely send it to T1 >> in order to avoid unnecessary relay hops. Likewise, if P1 asks T1 for an >> alternate to T3, it will get T3. They would get a more optimal >> end-to-end connection, but not the best end-to-end connection, since in >> this case, you want them to converge on T2. >> >> I think you could probably get to the same decision using the combined >> set of responses for both the server-reflexive candidate and the relayed >> candidate, but I think that the addition of this attribute can help the >> system to get you there faster. >> >> Do you have thoughts on this rationale? If it seems reasonable, then >> I'll add some detail about it to the next revision. > > Well, in this particular example: > > - I understand why having both TURN sessions terminate on the same > server is optimal. > > - I don't see how T2 is better than T1 or T3, assuming that T1 (resp. > T3) is "close" to P1 (resp. P3). As long as triangle routing is avoided, > it doesn't really matter that the TURN server be halfway between the > two. As long as it is close to the best path between P1 and P2, it's > optimal. Is that understanding correct? > > So my thinking is that since all TURN servers are under the same > administrative entity, we can expect that each server knows about the > others' IP addresses, and can redirect intelligently on a > CreatePermission or ChannelBind request containing one of the TURN > servers' IP address in the XOR-PEER-ADDRESS attribute. That is, it would > redirect the client to the peer's TURN server so that both TURN sessions > are terminated on the same server. So I don't see a need for > XOR-OTHER-ADDRESS in this case either. > > Simon > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Apr 7 08:24:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EE81A07B6 for ; Mon, 7 Apr 2014 08:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Va6Q3BwjBB7h for ; Mon, 7 Apr 2014 08:24:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 061D91A0799 for ; Mon, 7 Apr 2014 08:24:41 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0B9A647414 for ; Mon, 7 Apr 2014 15:24:36 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id EF802474D0 for ; Mon, 7 Apr 2014 15:24:35 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id C4F4A80047 for ; Mon, 7 Apr 2014 15:24:35 +0000 (GMT) Message-ID: <5342C331.5030108@akamai.com> Date: Mon, 07 Apr 2014 11:24:33 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140404165719.31339.3827.idtracker@ietfa.amsl.com> <533EE4F7.1020701@akamai.com> <533EED5A.1020409@viagenie.ca> <533F0886.4020201@akamai.com> <5342AE4C.10400@viagenie.ca> <5342BACB.3050303@akamai.com> In-Reply-To: <5342BACB.3050303@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XbKDIsS8kcfHl1eWE9GVKS5TZw8 Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:24:47 -0000 I suppose an alternative to allowing the client to signal the expected response type would be to always make it an error response. The client would send one request with the CHECK-ALTERNATE attribute and if the client still wishes to go ahead with this relay until the other relay is available, it could do so by sending a second request without the attribute. That would require an extra RTT in the use case where the client is trying to get the session set up faster, so it didn't seem ideal to me. --Brandon On 04/07/2014 10:48 AM, Brandon Williams wrote: > > Why does the client need this flexibility? What kind of external > > stimulus would cause the client to behave one way or the other? > > I see two different primary criteria: session establishment time vs > simplicity. > > If you want to optimize for faster session establishment, then you would > want to receive a "hint" that tells you where you will get better > service. This allows you to continue using the existing-but-suboptimal > allocation/binding while you are setting up the new allocation/binding. > This potentially has greater associated internal complexity, since > you've got to maintain multiple active associated sessions for the peer > pairing and figure out when it's OK to switch over. > > If you want to optimize for internal simplicity, then you probably just > want to get an error response and deal with the associated offer > updates, etc. There's only one activity to manage for the peer pairing > at any particular point in time. You risk taking a bit longer for > session establishment, but that might be a reasonable trade-off. > > The choice also has something to do with the application provider's > relationship to the relay provider, I think. A higher trust relationship > on the performance side could lead the application provider to desire > the simplicity of just switching over to another allocation/binding as > quickly as possible. A lower trust relationship (I know you think this > relay is better, but I want to check that myself) could lead the > application provider to want to run tests and make an internal decision > about which one to use. > > > - I don't see how T2 is better than T1 or T3, assuming that T1 (resp. > > T3) is "close" to P1 (resp. P3). As long as triangle routing is avoided, > > it doesn't really matter that the TURN server be halfway between the > > two. As long as it is close to the best path between P1 and P2, it's > > optimal. Is that understanding correct? > > > > So my thinking is that since all TURN servers are under the same > > administrative entity, we can expect that each server knows about the > > others' IP addresses, and can redirect intelligently on a > > CreatePermission or ChannelBind request containing one of the TURN > > servers' IP address in the XOR-PEER-ADDRESS attribute. That is, it would > > redirect the client to the peer's TURN server so that both TURN sessions > > are terminated on the same server. So I don't see a need for > > XOR-OTHER-ADDRESS in this case either. > > You're right that as long as the relay server for at least one of the > peers is very close to the peer itself, then that relay server will end > up being the best candidate (or at least a very good one). However, if > both of the current relay servers would end up resulting in triangle > routing, it's important to be able to figure that out, which requires > that you know both relay addresses and both peer addresses. > > --Brandon > > On 04/07/2014 09:55 AM, Simon Perreault wrote: >> Le 2014-04-04 15:31, Brandon Williams a écrit : >>> re: CHECK-ALTERNATE >>> CHECK-ALTERNATE serves two purposes: backward compatibility and client >>> flexibility. The client flexibility goal is spelled out in the >>> introduction, though I can see that the relationship between that >>> statement and the definition of the attribute isn't clearly stated. >> >> Assuming you're referring to this part: >> >> The client application indicates the nature of the desired >> response, which allows the client to treat the alternate server >> selection as either a requirement or a suggestion. This flexibility >> gives the client the option to choose the best way for the >> Interactive Connectivity Establishment (ICE) protocol [RFC5245] to >> respond (e.g. discarding the existing relay candidate for >> communication with this peer versus evaluating the two candidate >> servers using ICE connectivity checks and selecting the best one). >> >> Why does the client need this flexibility? What kind of external >> stimulus would cause the client to behave one way or the other? >> >>> i see now that the backward compatibility (prevent transmission of the >>> ALTERNATE-SERVER attribute to a client that doesn't support this use) >>> isn't stated anywhere. I'll be sure to clarify those points in the next >>> revision. >> >> Right, the ALTERNATE-SERVER mechanism as defined in RFC 5389 is >> optional. The problem is that there is no way for the server to know >> whether the client implements it or not. I see the need for capability >> signalling. >> >>> re: XOR-OTHER-ADDRESS >>> In a case where both clients to use TURN servers, you want them to >>> converge as quickly as possible on the pair that will provide the best >>> performance. Typically, the system will attempt to get them to use the >>> same relay server. If each one picks the TURN server that is best based >>> on its peer's relay address but the relay server was a bad pick in the >>> first place, then you'll frequently end up with a bad alternate and >>> never converge on a good pair. I think it requires a more complicated >>> example than the one in the introduction to really spell this out. >>> >>> Consider this case (T == TURN relay; P == peer): >>> >>> T1 <-- P1 T2 P2 --> T3 >>> >>> If T1, T2, and T3 are all part of the same system and P2 asks T3 for an >>> alternate server to get to T1, the system will most likely send it to T1 >>> in order to avoid unnecessary relay hops. Likewise, if P1 asks T1 for an >>> alternate to T3, it will get T3. They would get a more optimal >>> end-to-end connection, but not the best end-to-end connection, since in >>> this case, you want them to converge on T2. >>> >>> I think you could probably get to the same decision using the combined >>> set of responses for both the server-reflexive candidate and the relayed >>> candidate, but I think that the addition of this attribute can help the >>> system to get you there faster. >>> >>> Do you have thoughts on this rationale? If it seems reasonable, then >>> I'll add some detail about it to the next revision. >> >> Well, in this particular example: >> >> - I understand why having both TURN sessions terminate on the same >> server is optimal. >> >> - I don't see how T2 is better than T1 or T3, assuming that T1 (resp. >> T3) is "close" to P1 (resp. P3). As long as triangle routing is avoided, >> it doesn't really matter that the TURN server be halfway between the >> two. As long as it is close to the best path between P1 and P2, it's >> optimal. Is that understanding correct? >> >> So my thinking is that since all TURN servers are under the same >> administrative entity, we can expect that each server knows about the >> others' IP addresses, and can redirect intelligently on a >> CreatePermission or ChannelBind request containing one of the TURN >> servers' IP address in the XOR-PEER-ADDRESS attribute. That is, it would >> redirect the client to the peer's TURN server so that both TURN sessions >> are terminated on the same server. So I don't see a need for >> XOR-OTHER-ADDRESS in this case either. >> >> Simon >> > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Apr 7 11:33:18 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C773D1A0211 for ; Mon, 7 Apr 2014 11:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 W4ZAzKA6gXJR for ; Mon, 7 Apr 2014 11:33:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DB01F1A02B0 for ; Mon, 7 Apr 2014 11:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4018; q=dns/txt; s=iport; t=1396895581; x=1398105181; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=RrLNCCTIQIAvwhQxoqUB5aXmVrULdyBY7V+jwvavi84=; b=IyjEdL8S5/5yMdXFuBv/RebhCRmT2V/C6bjShz07q4lrJ6mUdBr26eVj LsWIG7cEMI386Yzwg/VGsefR4P3ez5MeIixMcZWzejMWPBWOTboO2wc84 WVtSqXki37E+Zw/LxPpTvJiF/OgAI4FJiJOcFRVOABiFShmBTZLwiL/nh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAALuQlOtJA2M/2dsb2JhbABZgwY7V8QkgSoWdIIlAQEBBB0KUgwGAQgRBAEBCw4MAzkUCQkBBAENBQiHca4XnXAXjigYMQ0SgwyBFASJIpBtkQuDMIFqQQ X-IronPort-AV: E=Sophos;i="4.97,812,1389744000"; d="scan'208";a="315836464" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 07 Apr 2014 18:33:01 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s37IX0OT009948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Apr 2014 18:33:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.98]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 13:33:00 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Oleg Moskalenko , Jonathan Lennox Thread-Topic: [tram] STUN hash agility Thread-Index: Ac9Sj8snapEOzWT1Q5eIrc1DgZiLlA== Date: Mon, 7 Apr 2014 18:33:00 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2430F90C@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.153] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lRxlT1anv4YfI5vIEgdBYHi8oEY Cc: "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 07 Apr 2014 18:33:17 -0000 The other point that we missed to discuss is that if Enterprise wants to le= verage the services of cloud (for e.g. Hybrid cloud) for deploying TURN ser= vers. Enterprise information security policy may not permit credentials to = be stored outside it's domain. Cheers, -Tiru > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) > Sent: Tuesday, April 01, 2014 5:45 PM > To: 'Simon Perreault'; Oleg Moskalenko; Jonathan Lennox > Cc: tram@ietf.org > Subject: RE: [tram] STUN hash agility >=20 > > -----Original Message----- > > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > > Sent: Friday, March 28, 2014 6:17 PM > > To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko; Jonathan Lennox > > Cc: tram@ietf.org > > Subject: Re: [tram] STUN hash agility > > > > Oooooh! I love playing the devil's advocate... :) >=20 > :) >=20 > > > > Le 2014-03-28 05:16, Tirumaleswar Reddy (tireddy) a =E9crit : > > > 1)TURN Server has to maintain the {username/realm/password} database > > > just like the AD server which is an overhead. > > > > Are you assuming that the TURN server cannot query the AD server > > instead of maintaining a duplicate database ? >=20 > TURN server can query the AD server. But this will be not be the typical > request/response used, in this case the request must contain (username, r= ealm) > asking for the password. >=20 > > > > In any case, database replication is easy and well understood. You > > need to have *lots* of accounts for e.g. dead-simple MySQL replication > > to not be sufficient. >=20 > Or the TURN server can establish connection with remote RDMS server and s= end > query to get the password. >=20 > > > > > 2)In a large Enterprise Network (for e.g. consider a large service > > > company) where NNN number of new users join, MMM users leave every > day. > > > It seems difficult to manage this credential database on the TURN > > > server to be in sync with the AD. > > > > Really? MySQL replication (for example) is dead simple. > > > > > 3)If each branch office in an large enterprise network wants to > > > deploy TURN servers, then the cost of TURN server includes > > > additional storage space and operational issues which may be a > > > concern of the I.T. > > > > I doubt this very much. You would need *lots* of user accounts for the > > password database to not fit on any regular-sized hard drive. > > > > About operations: once again, database replication is well understood > > and very common. >=20 > Database replication will work but it's an overhead in the above use case= . In > service based companies, where onboarding/off-boarding of users on daily = basis > is frequent, this would call for frequent database replication. If branc= h offices > want TURN server to be co-located with a router, it may not even have har= d- > drive to store this info. With the current limitation, software upgrade o= f the > router to support TURN server will not be sufficient. I.T will also have = to > purchase routers which come up hard drive. >=20 > Further a small branch/sales office of an Enterprise network may have onl= y few > hundred users in that site, it's an over-head to replicate the credential= s of the > entire org to this small site. >=20 > > > > > 4)AD server maintained in the Data Center usually has better > > > physical security than branch offices - what if someone breaks into > > > the branch office and steals all the username + password ? (I am > > > assuming the username, password are the same credentials used to > > > access other critical enterprise resources) > > > > Now this I totally buy. We need something better than > > MD5(username:realm:password). >=20 > Cheers, > -Tiru >=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 nobody Mon Apr 7 12:11:30 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395C31A0162 for ; Mon, 7 Apr 2014 12:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 VJRMdG_mTV82 for ; Mon, 7 Apr 2014 12:11:21 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 90A021A07A1 for ; Mon, 7 Apr 2014 12:11:11 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EB3A247552 for ; Mon, 7 Apr 2014 19:11:05 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 80C8F4752F for ; Mon, 7 Apr 2014 19:11:02 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 39EE4202E for ; Mon, 7 Apr 2014 19:11:02 +0000 (GMT) Message-ID: <5342F843.4010407@akamai.com> Date: Mon, 07 Apr 2014 15:10:59 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A2430F90C@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2430F90C@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PY4pJT3mZWH9MMHbJ5d_T-4fxYw Subject: Re: [tram] STUN hash agility 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, 07 Apr 2014 19:11:28 -0000 Isn't that problem more in the category of 3rd party auth improvements than hash agility? Or are you suggesting that the hashing mechanism to be used on the authentication information could make a difference in terms of whether or not it was viewed as violating that policy? --Brandon On 04/07/2014 02:33 PM, Tirumaleswar Reddy (tireddy) wrote: > The other point that we missed to discuss is that if Enterprise wants to leverage the services of cloud (for e.g. Hybrid cloud) for deploying TURN servers. Enterprise information security policy may not permit credentials to be stored outside it's domain. > > Cheers, > -Tiru > >> -----Original Message----- >> From: Tirumaleswar Reddy (tireddy) >> Sent: Tuesday, April 01, 2014 5:45 PM >> To: 'Simon Perreault'; Oleg Moskalenko; Jonathan Lennox >> Cc: tram@ietf.org >> Subject: RE: [tram] STUN hash agility >> >>> -----Original Message----- >>> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >>> Sent: Friday, March 28, 2014 6:17 PM >>> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko; Jonathan Lennox >>> Cc: tram@ietf.org >>> Subject: Re: [tram] STUN hash agility >>> >>> Oooooh! I love playing the devil's advocate... :) >> >> :) >> >>> >>> Le 2014-03-28 05:16, Tirumaleswar Reddy (tireddy) a écrit : >>>> 1)TURN Server has to maintain the {username/realm/password} database >>>> just like the AD server which is an overhead. >>> >>> Are you assuming that the TURN server cannot query the AD server >>> instead of maintaining a duplicate database ? >> >> TURN server can query the AD server. But this will be not be the typical >> request/response used, in this case the request must contain (username, realm) >> asking for the password. >> >>> >>> In any case, database replication is easy and well understood. You >>> need to have *lots* of accounts for e.g. dead-simple MySQL replication >>> to not be sufficient. >> >> Or the TURN server can establish connection with remote RDMS server and send >> query to get the password. >> >>> >>>> 2)In a large Enterprise Network (for e.g. consider a large service >>>> company) where NNN number of new users join, MMM users leave every >> day. >>>> It seems difficult to manage this credential database on the TURN >>>> server to be in sync with the AD. >>> >>> Really? MySQL replication (for example) is dead simple. >>> >>>> 3)If each branch office in an large enterprise network wants to >>>> deploy TURN servers, then the cost of TURN server includes >>>> additional storage space and operational issues which may be a >>>> concern of the I.T. >>> >>> I doubt this very much. You would need *lots* of user accounts for the >>> password database to not fit on any regular-sized hard drive. >>> >>> About operations: once again, database replication is well understood >>> and very common. >> >> Database replication will work but it's an overhead in the above use case. In >> service based companies, where onboarding/off-boarding of users on daily basis >> is frequent, this would call for frequent database replication. If branch offices >> want TURN server to be co-located with a router, it may not even have hard- >> drive to store this info. With the current limitation, software upgrade of the >> router to support TURN server will not be sufficient. I.T will also have to >> purchase routers which come up hard drive. >> >> Further a small branch/sales office of an Enterprise network may have only few >> hundred users in that site, it's an over-head to replicate the credentials of the >> entire org to this small site. >> >>> >>>> 4)AD server maintained in the Data Center usually has better >>>> physical security than branch offices - what if someone breaks into >>>> the branch office and steals all the username + password ? (I am >>>> assuming the username, password are the same credentials used to >>>> access other critical enterprise resources) >>> >>> Now this I totally buy. We need something better than >>> MD5(username:realm:password). >> >> Cheers, >> -Tiru >> >>> >>> 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 > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Apr 7 22:15:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED5E1A0122 for ; Mon, 7 Apr 2014 22:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 pDExDk6IuMou for ; Mon, 7 Apr 2014 22:15:09 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED631A0117 for ; Mon, 7 Apr 2014 22:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9054; q=dns/txt; s=iport; t=1396934104; x=1398143704; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hTAIAKKABVhCaf276nldULFZRWNWsbvRANXNoDv9iJI=; b=OC9E2lQCkQ33xZjz/6skqviW9WTLmSUh1WffCceb6T+/9X5vJ5Ko15D/ S8OAeXCe+TK4rvLifKp3VVOjdN+M4i8DuNql9aukySsbMELGkjmC9QL2l xzEXWnUvCjrHRcxz6HHWA7aVtJAjNvKaKNs/oIz5P7Es378q/RiTN9U9s o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAGWFQ1OtJV2d/2dsb2JhbABZgwY7V7xwhzeBHxZ0giUBAQEEAQEBJEcEBQ4EAgEIEQQBAQEKHQcnCxQJCAIEARIIh3ENynoTBIlDhHY4BoMegRQBA4kjiwlEliyBcYE/gis X-IronPort-AV: E=Sophos;i="4.97,815,1389744000"; d="scan'208";a="33847714" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 08 Apr 2014 05:14:59 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s385ExLA010173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 05:14:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.98]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 00:14:59 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-00.txt Thread-Index: AQHPUCxIdlkiZfIZtE6/ybNBrIakfZsCLF8AgARZJQCAAA7mgIAAl1fg Date: Tue, 8 Apr 2014 05:14:59 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A243100DC@xmb-rcd-x10.cisco.com> References: <20140404165719.31339.3827.idtracker@ietfa.amsl.com> <533EE4F7.1020701@akamai.com> <533EED5A.1020409@viagenie.ca> <533F0886.4020201@akamai.com> <5342AE4C.10400@viagenie.ca> <5342BACB.3050303@akamai.com> In-Reply-To: <5342BACB.3050303@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.87] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Qk1TL0Fr_2WBhUg_BbmaZPIsG3I Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 05:15:14 -0000 The other use case for supporting both modes is that, endpoint supports Tri= ckle ICE 1) Let's say remote peer also supports Trickle ICE. In this case error resp= onse will be useful, because endpoints would initially only advertise host = candidates. Thus both endpoints can learn the best suited TURN server using= the remote peer's host address (Public IPv6 address). If PCP is used then = server-reflexive candidates could also be learnt and advertised before rela= yed candidates and thus the alternate TURN server could be discovered using= remote peer's host/server-reflexive candidates. This way client has to adv= ertise the relayed candidate only once. 2) Remote peer does not support Trickle ICE. If both endpoints want faster = call setup then hint approach will be useful. If local relayed candidate is= nominated for media streams then ICE restart could be used to test and mig= rate the media session to the relayed candidate learnt from the alternate T= URN server. =20 -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Monday, April 07, 2014 8:19 PM > To: tram@ietf.org > Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer= - > redirect-00.txt >=20 > > Why does the client need this flexibility? What kind of external > st= imulus > would cause the client to behave one way or the other? >=20 > I see two different primary criteria: session establishment time vs simpl= icity. >=20 > If you want to optimize for faster session establishment, then you would = want to > receive a "hint" that tells you where you will get better service. This a= llows you > to continue using the existing-but-suboptimal allocation/binding while yo= u are > setting up the new allocation/binding. > This potentially has greater associated internal complexity, since you've= got to > maintain multiple active associated sessions for the peer pairing and fig= ure out > when it's OK to switch over. >=20 > If you want to optimize for internal simplicity, then you probably just w= ant to get > an error response and deal with the associated offer updates, etc. There'= s only > one activity to manage for the peer pairing at any particular point in ti= me. You > risk taking a bit longer for session establishment, but that might be a r= easonable > trade-off. >=20 > The choice also has something to do with the application provider's relat= ionship > to the relay provider, I think. A higher trust relationship on the perfor= mance side > could lead the application provider to desire the simplicity of just swit= ching over > to another allocation/binding as quickly as possible. A lower trust relat= ionship (I > know you think this relay is better, but I want to check that myself) cou= ld lead > the application provider to want to run tests and make an internal decisi= on > about which one to use. >=20 > > - I don't see how T2 is better than T1 or T3, assuming that T1 (resp. > > T3) is "close" to P1 (resp. P3). As long as triangle routing is avoide= d, > it > doesn't really matter that the TURN server be halfway between the > two.= As > long as it is close to the best path between P1 and P2, it's > optimal. = Is that > understanding correct? > > > > So my thinking is that since all TURN servers are under the same > > administrative entity, we can expect that each server knows about the > = others' > IP addresses, and can redirect intelligently on a > CreatePermission or > ChannelBind request containing one of the TURN > servers' IP address in = the > XOR-PEER-ADDRESS attribute. That is, it would > redirect the client to t= he peer's > TURN server so that both TURN sessions > are terminated on the same serv= er. > So I don't see a need for > XOR-OTHER-ADDRESS in this case either. >=20 > You're right that as long as the relay server for at least one of the pee= rs is very > close to the peer itself, then that relay server will end up being the be= st > candidate (or at least a very good one). However, if both of the current = relay > servers would end up resulting in triangle routing, it's important to be = able to > figure that out, which requires that you know both relay addresses and bo= th peer > addresses. >=20 > --Brandon >=20 > On 04/07/2014 09:55 AM, Simon Perreault wrote: > > Le 2014-04-04 15:31, Brandon Williams a =E9crit : > >> re: CHECK-ALTERNATE > >> CHECK-ALTERNATE serves two purposes: backward compatibility and > >> client flexibility. The client flexibility goal is spelled out in the > >> introduction, though I can see that the relationship between that > >> statement and the definition of the attribute isn't clearly stated. > > > > Assuming you're referring to this part: > > > > The client application indicates the nature of the desired > > response, which allows the client to treat the alternate server > > selection as either a requirement or a suggestion. This flexibilit= y > > gives the client the option to choose the best way for the > > Interactive Connectivity Establishment (ICE) protocol [RFC5245] to > > respond (e.g. discarding the existing relay candidate for > > communication with this peer versus evaluating the two candidate > > servers using ICE connectivity checks and selecting the best one). > > > > Why does the client need this flexibility? What kind of external > > stimulus would cause the client to behave one way or the other? > > > >> i see now that the backward compatibility (prevent transmission of > >> the ALTERNATE-SERVER attribute to a client that doesn't support this > >> use) isn't stated anywhere. I'll be sure to clarify those points in > >> the next revision. > > > > Right, the ALTERNATE-SERVER mechanism as defined in RFC 5389 is > > optional. The problem is that there is no way for the server to know > > whether the client implements it or not. I see the need for capability > > signalling. > > > >> re: XOR-OTHER-ADDRESS > >> In a case where both clients to use TURN servers, you want them to > >> converge as quickly as possible on the pair that will provide the > >> best performance. Typically, the system will attempt to get them to > >> use the same relay server. If each one picks the TURN server that is > >> best based on its peer's relay address but the relay server was a bad > >> pick in the first place, then you'll frequently end up with a bad > >> alternate and never converge on a good pair. I think it requires a > >> more complicated example than the one in the introduction to really sp= ell this > out. > >> > >> Consider this case (T =3D=3D TURN relay; P =3D=3D peer): > >> > >> T1 <-- P1 T2 P2 --> T3 > >> > >> If T1, T2, and T3 are all part of the same system and P2 asks T3 for > >> an alternate server to get to T1, the system will most likely send it > >> to T1 in order to avoid unnecessary relay hops. Likewise, if P1 asks > >> T1 for an alternate to T3, it will get T3. They would get a more > >> optimal end-to-end connection, but not the best end-to-end > >> connection, since in this case, you want them to converge on T2. > >> > >> I think you could probably get to the same decision using the > >> combined set of responses for both the server-reflexive candidate and > >> the relayed candidate, but I think that the addition of this > >> attribute can help the system to get you there faster. > >> > >> Do you have thoughts on this rationale? If it seems reasonable, then > >> I'll add some detail about it to the next revision. > > > > Well, in this particular example: > > > > - I understand why having both TURN sessions terminate on the same > > server is optimal. > > > > - I don't see how T2 is better than T1 or T3, assuming that T1 (resp. > > T3) is "close" to P1 (resp. P3). As long as triangle routing is > > avoided, it doesn't really matter that the TURN server be halfway > > between the two. As long as it is close to the best path between P1 > > and P2, it's optimal. Is that understanding correct? > > > > So my thinking is that since all TURN servers are under the same > > administrative entity, we can expect that each server knows about the > > others' IP addresses, and can redirect intelligently on a > > CreatePermission or ChannelBind request containing one of the TURN > > servers' IP address in the XOR-PEER-ADDRESS attribute. That is, it > > would redirect the client to the peer's TURN server so that both TURN > > sessions are terminated on the same server. So I don't see a need for > > XOR-OTHER-ADDRESS in this case either. > > > > Simon > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Apr 7 22:46:42 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C5A1A0133 for ; Mon, 7 Apr 2014 22:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 E_fNR0RXV6-S for ; Mon, 7 Apr 2014 22:46:35 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id A1FFA1A012C for ; Mon, 7 Apr 2014 22:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7712; q=dns/txt; s=iport; t=1396935990; x=1398145590; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nmcd29pdqbTkyh8yOEAw9Iy6xlXSBuAFuz+g6Ea5k5o=; b=QrV8bGjFvpP3nHcnSKfB/RXaL2uz+E/yf0iilHcQdk4g+GD1ro1HMhTb AQEL7/A/Hhd4pAUvGSZR7p1WlQ00iABJGm4nlC+smqdC4dmZkMK3ca0Yf PiLCIQvRMZnhdLfbuqCjuBSvuWoKhvyR0oDK7W3cDpa2yKpCoIswWXGWr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIFAKeMQ1OtJV2b/2dsb2JhbABZgkJEO1e7MYE/hzeBHxZ0giUBAQEDAQEBASpBCwULAgEIDgMEAQELHQcnCxQJCAIEAQ0FCIdpCA3KZReOOS0EBgGDJIEUBIkjkG2RDIFxgT+CKw X-IronPort-AV: E=Sophos; i="4.97,815,1389744000"; d="scan'208,217"; a="33852750" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 08 Apr 2014 05:46:29 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s385kTVi019658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 05:46:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.98]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 00:46:29 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: AQHPT+yZvUynsYQs1k6AEQn6+QFgjJsByeWAgABJJ4CAAAB2AIAAAnsAgAAjvYCABPpwUA== Date: Tue, 8 Apr 2014 05:46:28 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@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.74.87] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A24310130xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/mlM_Sw2keGH58ndk1KYetWQAHeo Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 05:46:40 -0000 --_000_913383AAA69FF945B8F946018B75898A24310130xmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yup, ALPN will be common for both TLS and DTLS. I see that http://tools.iet= f.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2 a= nd http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3 als= o discuss ALPN. we will need one place holder draft talking about all the n= ecessary ALPN identifiers. -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Saturday, April 05, 2014 1:47 AM To: Gonzalo Salgueiro (gsalguei) Cc: Simon Perreault; tram@ietf.org Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-= stun-dtls-01.txt] If ALPN is really independent of DTLS, I see no reason why they have to be = combined in the draft document that was created solely for the DTLS feature= introduction for STUNl. On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) > wrote: On Apr 4, 2014, at 2:00 PM, Simon Perreault > wrote: > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit : >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't seem= it should be buried in STUNoDTLS. Shall we produce a dedicated draft for = this? > > My preference would be for "buried in STUNoDTLS". :) But I'm open to argu= ments for a dedicated draft. My position is that the ALPN reg is entirely independent of STUNoDTLS, whic= h is why we considered more contextually relevant for the broader STUNbis e= ffort. A standalone dedicated ALPN reg doc to point to seems cleaner to me= , but I'm open to WG decision on this. -G > > Simon _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_913383AAA69FF945B8F946018B75898A24310130xmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yup, ALPN will be common = for both TLS and DTLS. I see that http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-= 03#section-4.2 and http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3<= /a> also discuss ALPN. we will need one place holder draft talking about al= l the necessary ALPN identifiers.

 <= /p>

-Tiru

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Saturday, April 05, 2014 1:47 AM
To: Gonzalo Salgueiro (gsalguei)
Cc: Simon Perreault; tram@ietf.org
Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-iet= f-tram-stun-dtls-01.txt]

 

If ALPN is really independent of DTLS, I see no reas= on why they have to be combined in the draft document that was created sole= ly for the DTLS feature introduction for STUNl.

 

On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (= gsalguei) <gsalg= uei@cisco.com> wrote:


On Apr 4, 2014, at 2:00 PM, Simon Perreault <simon.perreault@viagenie.ca> wrote:

> Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit :
>> Understood.  Nonetheless, even if not a part of STUNbis, it d= oesn't seem it should be buried in STUNoDTLS.  Shall we produce a dedi= cated draft for this?
>
> My preference would be for "buried in STUNoDTLS". :) But I'm= open to arguments for a dedicated draft.

My position is that the ALPN reg is entirely indepen= dent of STUNoDTLS, which is why we considered more contextually relevant fo= r the broader STUNbis effort.  A standalone dedicated ALPN reg doc to = point to seems cleaner to me, but I'm open to WG decision on this.

-G


>
> Simon

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

 

--_000_913383AAA69FF945B8F946018B75898A24310130xmbrcdx10ciscoc_-- From nobody Mon Apr 7 22:59:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02DC1A0140 for ; Mon, 7 Apr 2014 22:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ReAnQ4SnDGZa for ; Mon, 7 Apr 2014 22:59:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AE67D1A012F for ; Mon, 7 Apr 2014 22:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2010; q=dns/txt; s=iport; t=1396936773; x=1398146373; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3KZ/LZF1afoyPwK4GhyYDYutVdhmta1ouYsLRGkQxL0=; b=Cx4wqVzCFyIqYPsZnQFz9W1LeAH+0H8YLfnsTfCJMtKCHc0qaH37dQs+ /ZJ9bK1vIZ7uX2POUweJGTFW0sc3aVRlApkCo8W3lMJjbVXMYlp3q6Bfp 1WVYq1tlG/rllbV8C85C2Y39DSM+1Ez5CK5fWmsZ/64PwppY7gwpgpgWw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAPOPQ1OtJV2c/2dsb2JhbABZgwY7Swy8cIc3gR8WdIIlAQEBAwEBAQEmRQsFCwIBAgYRBAEBAScHJwsUCQgCBA4Fh3EIDcpSF443MweDJIEUBIkjjzmBNJEMgXGBP4Ir X-IronPort-AV: E=Sophos;i="4.97,816,1389744000"; d="scan'208";a="315951335" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 08 Apr 2014 05:59:26 +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 s385xQNK022922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 05:59:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.55]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 00:59:26 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: AQHPT+yZJikTBgKlDUC8PeejTqIjLZsByeWAgABJJ4CAAAB2AIAAAnsAgAAjvYCABPpwUIAAXzMA Importance: high X-Priority: 1 Date: Tue, 8 Apr 2014 05:59:26 +0000 Message-ID: References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.59] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4KoCHrA3ahqkzT2eSTXGRced_tU Cc: Simon Perreault , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 05:59:45 -0000 Agreed. We can try and put something together. -G =20 On Apr 8, 2014, at 1:46 AM, Tirumaleswar Reddy (tireddy) wrote: > Yup, ALPN will be common for both TLS and DTLS. I see that http://tools.i= etf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2= and http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3 a= lso discuss ALPN. we will need one place holder draft talking about all the= necessary ALPN identifiers. > =20 > -Tiru > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko > Sent: Saturday, April 05, 2014 1:47 AM > To: Gonzalo Salgueiro (gsalguei) > Cc: Simon Perreault; tram@ietf.org > Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tra= m-stun-dtls-01.txt] > =20 > If ALPN is really independent of DTLS, I see no reason why they have to b= e combined in the draft document that was created solely for the DTLS featu= re introduction for STUNl. > =20 >=20 > On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) wrote: >=20 > On Apr 4, 2014, at 2:00 PM, Simon Perreault = wrote: >=20 > > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit : > >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't se= em it should be buried in STUNoDTLS. Shall we produce a dedicated draft fo= r this? > > > > My preference would be for "buried in STUNoDTLS". :) But I'm open to ar= guments for a dedicated draft. >=20 > My position is that the ALPN reg is entirely independent of STUNoDTLS, wh= ich is why we considered more contextually relevant for the broader STUNbis= effort. A standalone dedicated ALPN reg doc to point to seems cleaner to = me, but I'm open to WG decision on this. >=20 > -G >=20 > > > > Simon >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > =20 From nobody Mon Apr 7 23:13:24 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44E91A0032 for ; Mon, 7 Apr 2014 23:13:20 -0700 (PDT) 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 Rxhy2HZPWfBT for ; Mon, 7 Apr 2014 23:13:16 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 649381A010B for ; Mon, 7 Apr 2014 23:13:10 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id v10so551702pde.1 for ; Mon, 07 Apr 2014 23:13:04 -0700 (PDT) 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=wmejRr8HfektTy6MFRo4M5/aSNzO7NNbO/s+LbUgqoU=; b=eb+//mYeuu8+/8dKxSFGd75JafS3LbtCVI2Dv1Mn8zwQ62/w1C4ONmfiLPcV00O+lR qySyfNE1/BhMBi/qqgSLW0cE/qItKTNCU8Ca4Lvui0Lhge3CkBM01+pvJrTKDRvEenqb M4p91NuRT1juu7Atr3qkloejIJVAZxtt73CpV6Ys7F7pusAobdvEnGfr/UA6bUUucF95 o8orWvNjQnyCoApRMzk93waoMDWL9Gtxjc1CWeg6I5LLcSqJ1c1+fj0F0DaEow/B8qdA hrQ/kdKffE5n2v7jJxWlqcbMcwOct33KIxBiNZwTgSORS0vHTaFx6Aevbxl3nAI6MQ9O F6Xg== MIME-Version: 1.0 X-Received: by 10.68.217.234 with SMTP id pb10mr2209466pbc.142.1396937584581; Mon, 07 Apr 2014 23:13:04 -0700 (PDT) Received: by 10.68.151.97 with HTTP; Mon, 7 Apr 2014 23:13:04 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> Date: Mon, 7 Apr 2014 23:13:04 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b2edaa780a33f04f681e0dc Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-7aObAqWzvKemum7iZV6wKsXl0M Cc: Simon Perreault , "Gonzalo Salgueiro \(gsalguei\)" , "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 06:13:21 -0000 --047d7b2edaa780a33f04f681e0dc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that ALPN draft has to be a separate dedicated to ALPN draft. We already have TLS in TURN. The DTLS draft simply corrects that asymmetry and makes DTLS on the same level as TLS. That is logically a separate task from adding ALPN to both TLS and DTLS. I'd keep those two things as sequential separate drafts. Mixing them is introducing a sort of mess into the process= . Oleg On Mon, Apr 7, 2014 at 10:46 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Yup, ALPN will be common for both TLS and DTLS. I see that > http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideration= s-03#section-4.2and > http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3 also > discuss ALPN. we will need one place holder draft talking about all the > necessary ALPN identifiers. > > > > -Tiru > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg Moskalenk= o > *Sent:* Saturday, April 05, 2014 1:47 AM > *To:* Gonzalo Salgueiro (gsalguei) > *Cc:* Simon Perreault; tram@ietf.org > *Subject:* Re: [tram] ALPN Registration [was Re: I-D Action: > draft-ietf-tram-stun-dtls-01.txt] > > > > If ALPN is really independent of DTLS, I see no reason why they have to b= e > combined in the draft document that was created solely for the DTLS featu= re > introduction for STUNl. > > > > On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) < > gsalguei@cisco.com> wrote: > > > On Apr 4, 2014, at 2:00 PM, Simon Perreault > wrote: > > > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit : > >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't > seem it should be buried in STUNoDTLS. Shall we produce a dedicated draf= t > for this? > > > > My preference would be for "buried in STUNoDTLS". :) But I'm open to > arguments for a dedicated draft. > > My position is that the ALPN reg is entirely independent of STUNoDTLS, > which is why we considered more contextually relevant for the broader > STUNbis effort. A standalone dedicated ALPN reg doc to point to seems > cleaner to me, but I'm open to WG decision on this. > > -G > > > > > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > --047d7b2edaa780a33f04f681e0dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think that ALPN draft has to be a separate dedicate= d to ALPN draft. We already have TLS in TURN. The DTLS draft simply correct= s that asymmetry and makes DTLS on the same level as TLS. That is logically= a separate task from adding ALPN to both TLS and DTLS. I'd keep those = two things as sequential separate drafts. Mixing them is introducing a sort= of mess into the process.

Oleg



On Mon, Apr 7, 2014 at 10:46 PM, Tirumaleswar Reddy (tired= dy) <tireddy@cisco.com> wrote:

Yup, ALPN will be common = for both TLS and DTLS. I see that http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-= 03#section-4.2 and http://tools.ietf.org/html/draft-thomson-rtcweb-con= sent-00#section-3 also discuss ALPN. we will need one place holder draf= t talking about all the necessary ALPN identifiers.

=A0<= /p>

-Tiru

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Saturday, April 05, 2014 1:47 AM
To: Gonzalo Salgueiro (gsalguei)
Cc: Simon Perreault; tram@ietf.org
Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-iet= f-tram-stun-dtls-01.txt]

=A0

If ALPN is really independent of DTLS, I see no reas= on why they have to be combined in the draft document that was created sole= ly for the DTLS feature introduction for STUNl.

=A0

On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (= gsalguei) <gsalg= uei@cisco.com> wrote:


On Apr 4, 2014, at 2:00 PM, Simon Perreault <simon.perreault@viagenie.ca> w= rote:

> Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit :
>> Understood. =A0Nonetheless, even if not a part of STUNbis, it does= n't seem it should be buried in STUNoDTLS. =A0Shall we produce a dedica= ted draft for this?
>
> My preference would be for "buried in STUNoDTLS". :) But I&#= 39;m open to arguments for a dedicated draft.

My position is that the ALPN reg is entirely indepen= dent of STUNoDTLS, which is why we considered more contextually relevant fo= r the broader STUNbis effort. =A0A standalone dedicated ALPN reg doc to poi= nt to seems cleaner to me, but I'm open to WG decision on this.

-G


>
> Simon

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

=A0


--047d7b2edaa780a33f04f681e0dc-- From nobody Tue Apr 8 02:27:21 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5454F1A0219 for ; Tue, 8 Apr 2014 02:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 m-PH8McsEjvQ for ; Tue, 8 Apr 2014 02:27:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E00061A01F8 for ; Tue, 8 Apr 2014 02:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14034; q=dns/txt; s=iport; t=1396949186; x=1398158786; h=from:to:cc:subject:date:message-id:mime-version; bh=5KttjwYr65R6sxh8oqPMRskryn/QalQTVrHOnccJfCM=; b=c4PFIrHmpd2/P8CONPHZPz/x0kymCRc5I+eWXCwKccV4LAVvoDW6XDym 6DdPvgpM41V9ofI5nclbV1HIywcjVBAyDojj+sX8Mhd0Tjfx1XNI7gdsj j6qBrgzLSpD/Dodljghw1cdc5KuQZqZQEdaIUU7LwiunSXUy6YXDrft61 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAAHAQ1OtJV2a/2dsb2JhbABZgkJEO1e7LYE/hzeBHxZ0giUBAQEDAQEBASpBCwUNAQgOAwQBAQsdKAYLFAkJAQQOBQiHXQMJCA3DJg2GaxeMUYFoLQQGgyWBFASJI41MgyGLPYVPgXGBP4Ir X-IronPort-AV: E=Sophos;i="4.97,816,1389744000"; d="scan'208,217";a="315829564" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 08 Apr 2014 09:26:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s389QP6e017793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 09:26:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.98]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 04:26:25 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: Ac9TDJmRbri8jxDOSPGjNHo8bUxIog== Date: Tue, 8 Apr 2014 09:26:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24310286@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.61] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A24310286xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7i7iau_VfaB-cRzxCrirgz1HlOM Cc: Simon Perreault , "Gonzalo Salgueiro \(gsalguei\)" , "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 09:27:19 -0000 --_000_913383AAA69FF945B8F946018B75898A24310286xmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Oleg, Please see inline [TR] From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Tuesday, April 08, 2014 11:43 AM To: Tirumaleswar Reddy (tireddy) Cc: Gonzalo Salgueiro (gsalguei); Simon Perreault; tram@ietf.org Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-= stun-dtls-01.txt] I think that ALPN draft has to be a separate dedicated to ALPN draft. [TR] Agreed. We already have TLS in TURN. The DTLS draft simply corrects that asymmetry = and makes DTLS on the same level as TLS. That is logically a separate task = from adding ALPN to both TLS and DTLS. [TR] ALPN remains same for both TLS and DTLS. ALPN draft can explicitly say= it's applicable for both TLS and DTLS. Since DTLS draft is already a WG mi= lestone, I guess it will not stop the progress of ALPN draft. -Tiru I'd keep those two things as sequential separate drafts. Mixing them is int= roducing a sort of mess into the process. Oleg On Mon, Apr 7, 2014 at 10:46 PM, Tirumaleswar Reddy (tireddy) > wrote: Yup, ALPN will be common for both TLS and DTLS. I see that http://tools.iet= f.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2 a= nd http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3 als= o discuss ALPN. we will need one place holder draft talking about all the n= ecessary ALPN identifiers. -Tiru From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Oleg Moskalenko Sent: Saturday, April 05, 2014 1:47 AM To: Gonzalo Salgueiro (gsalguei) Cc: Simon Perreault; tram@ietf.org Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-= stun-dtls-01.txt] If ALPN is really independent of DTLS, I see no reason why they have to be = combined in the draft document that was created solely for the DTLS feature= introduction for STUNl. On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) > wrote: On Apr 4, 2014, at 2:00 PM, Simon Perreault > wrote: > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit : >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't seem= it should be buried in STUNoDTLS. Shall we produce a dedicated draft for = this? > > My preference would be for "buried in STUNoDTLS". :) But I'm open to argu= ments for a dedicated draft. My position is that the ALPN reg is entirely independent of STUNoDTLS, whic= h is why we considered more contextually relevant for the broader STUNbis e= ffort. A standalone dedicated ALPN reg doc to point to seems cleaner to me= , but I'm open to WG decision on this. -G > > Simon _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_913383AAA69FF945B8F946018B75898A24310286xmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Oleg,

 <= /p>

Please see inline [TR]

 <= /p>

From: Oleg Mos= kalenko [mailto:mom040267@gmail.com]
Sent: Tuesday, April 08, 2014 11:43 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Gonzalo Salgueiro (gsalguei); Simon Perreault; tram@ietf.org
Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-iet= f-tram-stun-dtls-01.txt]

 

I think that ALPN dra= ft has to be a separate dedicated to ALPN draft.

[TR] Agreed.

We already have TLS i= n TURN. The DTLS draft simply corrects that asymmetry and makes DTLS on the= same level as TLS. That is logically a separate task from adding ALPN to b= oth TLS and DTLS.

[TR] ALPN remains same for both TLS and DTLS. ALPN draft can explicit= ly say it’s applicable for both TLS and DTLS. Since DTLS draft is already a WG milestone, I guess it will not stop the progress of ALPN d= raft.

-Tiru

I'd keep those two th= ings as sequential separate drafts. Mixing them is introducing a sort of me= ss into the process.

Oleg

 

On Mon, Apr 7, 2014 at 10:46 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Yup, ALPN will be common for both TLS a= nd DTLS. I see that http://too= ls.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section= -4.2 and http://tools.ietf.org/html= /draft-thomson-rtcweb-consent-00#section-3 also discuss ALPN. we will need one place holder draft talking about all t= he necessary ALPN identifiers.

 

-Tiru

From: tram [mailto:tram-b= ounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Saturday, April 05, 2014 1:47 AM
To: Gonzalo Salgueiro (gsalguei)
Cc: Simon Perreault; tram@ietf.org
Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-iet= f-tram-stun-dtls-01.txt]

 

If ALPN is really independent of DTLS, I see no reason why they ha= ve to be combined in the draft document that was created solely for the DTL= S feature introduction for STUNl.

 

On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) <= gsalguei@cisco.com<= /a>> wrote:


On Apr 4, 2014, at 2:00 PM, Simon Perreault <simon.perreault@viagenie.ca> w= rote:

> Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit :
>> Understood.  Nonetheless, even if not a part of STUNbis, it d= oesn't seem it should be buried in STUNoDTLS.  Shall we produce a dedi= cated draft for this?
>
> My preference would be for "buried in STUNoDTLS". :) But I'm= open to arguments for a dedicated draft.

My position is that the ALPN reg is entirely independent of STUNoD= TLS, which is why we considered more contextually relevant for the broader = STUNbis effort.  A standalone dedicated ALPN reg doc to point to seems cleaner to me, but I'm open to WG decision = on this.

-G


>
> Simon

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

 

 

--_000_913383AAA69FF945B8F946018B75898A24310286xmbrcdx10ciscoc_-- From nobody Tue Apr 8 08:57:23 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA201A044B for ; Tue, 8 Apr 2014 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 LcvrTW3VsUyc for ; Tue, 8 Apr 2014 08:57:18 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id EBBA81A03C1 for ; Tue, 8 Apr 2014 08:57:17 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id nRCn1n00227AodY5ATxHzT; Tue, 08 Apr 2014 15:57:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id nTxH1n00i3ZTu2S3fTxHxJ; Tue, 08 Apr 2014 15:57:17 +0000 Message-ID: <53441C5D.3070009@alum.mit.edu> Date: Tue, 08 Apr 2014 11:57:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> 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=q20140121; t=1396972637; bh=sUYKYfsXmmlDmJPG3SkeHyTtNkgWgM68nBNSgI2mV5g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E6wSvFXAGxk4CS9NqmptgfOFyz9EWsJURjnqXJlsilo2HXXKKGOM+LgGJ+7UoHlcC cicViTpkJ4+/zLFSEsN0xEf+uwEXzcPhCbN3JPxG75c7XF3kMpjhbVo7YhgNORatBd vXiwDAMxIqQLnbgYaEh1NahJ4dQ3g5ecaFD588d+3ChvybjSMU8sjNQb7RhCG0FrN5 SZ+I7fA9dHKGGYnEwNiebDdHgX4DmPd7GYSMqboDg6L2bQFLx0tUNYDLRYiFzcMnHA aY6vixiJ0q2XD8GvRqneSvBH2BMrnlw2BtF7RxHBurjldeKwt4/Jw8LZR6VmZNjWnr nyzYJ2Fd+z9LQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/QXB_0DAFlCuau5S2H8-U1yx4m0A Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 15:57:22 -0000 On 4/8/14 1:46 AM, Tirumaleswar Reddy (tireddy) wrote: > Yup, ALPN will be common for both TLS and DTLS. *Why* would ALPN be common for TLS and DTLS? The characteristics of those transports are very different, so that it would be very rare for one higher level protocol to be usable over both. Thanks, Paul > I see that > http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2 > and http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3 > also discuss ALPN. we will need one place holder draft talking about all > the necessary ALPN identifiers. > > -Tiru > > *From:*tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg Moskalenko > *Sent:* Saturday, April 05, 2014 1:47 AM > *To:* Gonzalo Salgueiro (gsalguei) > *Cc:* Simon Perreault; tram@ietf.org > *Subject:* Re: [tram] ALPN Registration [was Re: I-D Action: > draft-ietf-tram-stun-dtls-01.txt] > > If ALPN is really independent of DTLS, I see no reason why they have to > be combined in the draft document that was created solely for the DTLS > feature introduction for STUNl. > > On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) > > wrote: > > > On Apr 4, 2014, at 2:00 PM, Simon Perreault > wrote: > > > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a écrit : > >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't > seem it should be buried in STUNoDTLS. Shall we produce a dedicated > draft for this? > > > > My preference would be for "buried in STUNoDTLS". :) But I'm open to > arguments for a dedicated draft. > > My position is that the ALPN reg is entirely independent of STUNoDTLS, > which is why we considered more contextually relevant for the broader > STUNbis effort. A standalone dedicated ALPN reg doc to point to seems > cleaner to me, but I'm open to WG decision on this. > > -G > > > > > > Simon > > _______________________________________________ > 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 nobody Tue Apr 8 10:24:33 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA821A01F2 for ; Tue, 8 Apr 2014 10:24:30 -0700 (PDT) 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 TjQFylUuNFlO for ; Tue, 8 Apr 2014 10:24:26 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 358121A064A for ; Tue, 8 Apr 2014 10:24:24 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so8262607wib.1 for ; Tue, 08 Apr 2014 10:24:24 -0700 (PDT) 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=csR/vU+L7K2pU8MdDKIaa4vFCnSKCCSbnW7tqVcf6MM=; b=MDTYjPH75sxFbR+wusYGzgyb8nB6D16ja+yAjBuyD67BxPkc0HnNH5PuObJGLUPL+O Wh5wV6ant0vrAXl43i5/4cu6v+A/8NlhtcfT3UXW0if2x6Rpa4mA8PgpXatUQz0jTzgJ mPVdCCySVyj2h8GYUE0sFZ7wjgKkNbjf19f5Jd+HxS4FNWECAIwZ88NH8nw4cikW85Yi 4Sk7EK0naWXElkeUIAizSy9fqxPq6YOOlK2X/fYw43IMMo1ty1ItnocVR46FXAypmOLq +zWERvszBH2V7C+3UxVWCejxv5/tCX3lUqrH9GNAtoUEBO/c+U07dzFe9FGh1khe0I+Z uMLw== MIME-Version: 1.0 X-Received: by 10.180.85.134 with SMTP id h6mr33055131wiz.44.1396977864345; Tue, 08 Apr 2014 10:24:24 -0700 (PDT) Received: by 10.194.9.67 with HTTP; Tue, 8 Apr 2014 10:24:24 -0700 (PDT) In-Reply-To: <53441C5D.3070009@alum.mit.edu> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> <53441C5D.3070009@alum.mit.edu> Date: Tue, 8 Apr 2014 10:24:24 -0700 Message-ID: From: Oleg Moskalenko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0444e9d35d0e4004f68b4149 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/3bRrl_E5BQljdQfbbuvELKpO-CA Cc: "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 17:24:30 -0000 --f46d0444e9d35d0e4004f68b4149 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable TLS and DTLS are indeed two different protocols with different characteristics. But in application to TURN, both carry, in most cases, the same content (the same application-level protocol suite): RTP, RTCP, SRTP. So I suppose that ALPN will be very similar for both TLS and DTLS. Then, why not consider them together ? On Tue, Apr 8, 2014 at 8:57 AM, Paul Kyzivat wrote: > On 4/8/14 1:46 AM, Tirumaleswar Reddy (tireddy) wrote: > >> Yup, ALPN will be common for both TLS and DTLS. >> > > *Why* would ALPN be common for TLS and DTLS? The characteristics of those > transports are very different, so that it would be very rare for one high= er > level protocol to be usable over both. > > Thanks, > Paul > > I see that >> http://tools.ietf.org/html/draft-hutton-rtcweb-nat- >> firewall-considerations-03#section-4.2 >> and http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00#section-3 >> also discuss ALPN. we will need one place holder draft talking about all >> the necessary ALPN identifiers. >> >> -Tiru >> >> *From:*tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg Moskalenk= o >> *Sent:* Saturday, April 05, 2014 1:47 AM >> *To:* Gonzalo Salgueiro (gsalguei) >> *Cc:* Simon Perreault; tram@ietf.org >> *Subject:* Re: [tram] ALPN Registration [was Re: I-D Action: >> >> draft-ietf-tram-stun-dtls-01.txt] >> >> If ALPN is really independent of DTLS, I see no reason why they have to >> be combined in the draft document that was created solely for the DTLS >> feature introduction for STUNl. >> >> On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) >> > wrote: >> >> >> On Apr 4, 2014, at 2:00 PM, Simon Perreault > > wrote: >> >> > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit : >> >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't >> seem it should be buried in STUNoDTLS. Shall we produce a dedicated >> draft for this? >> > >> > My preference would be for "buried in STUNoDTLS". :) But I'm open to >> arguments for a dedicated draft. >> >> My position is that the ALPN reg is entirely independent of STUNoDTLS, >> which is why we considered more contextually relevant for the broader >> STUNbis effort. A standalone dedicated ALPN reg doc to point to seems >> cleaner to me, but I'm open to WG decision on this. >> >> -G >> >> >> > >> > Simon >> >> _______________________________________________ >> 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 > --f46d0444e9d35d0e4004f68b4149 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
TLS and DTLS are indeed two different protocols with diffe= rent characteristics. But in application to TURN, both carry, in most cases= , the same content (the same application-level protocol suite): RTP, RTCP, = SRTP. So I suppose that ALPN will be very similar for both TLS and DTLS. Th= en, why not consider them together ?


On Tue,= Apr 8, 2014 at 8:57 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 4/8/14 1:46 AM, Tirumales= war Reddy (tireddy) wrote:
Yup, ALPN will be common for both TLS and DTLS.

*Why* would ALPN be common for TLS and DTLS? The characteristics of those t= ransports are very different, so that it would be very rare for one higher = level protocol to be usable over both.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

I see that
http://tools.ietf.org/html/= draft-hutton-rtcweb-nat-firewall-considerations-03#sectio= n-4.2
and http://tools.ietf.org/html/draft-thomson= -rtcweb-consent-00#section-3
also discuss ALPN. we will need one place holder draft talking about all the necessary ALPN identifiers.

-Tiru

*From:*tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg Moskalenko
*Sent:* Saturday, April 05, 2014 1:47 AM
*To:* Gonzalo Salgueiro (gsalguei)
*Cc:* Simon Perreault; t= ram@ietf.org
*Subject:* Re: [tram] ALPN Registration [was Re: I-D Action:

draft-ietf-tram-stun-dtls-01.txt]

If ALPN is really independent of DTLS, I see no reason why they have to
be combined in the draft document that was created solely for the DTLS
feature introduction for STUNl.

On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei)
<gsalguei@cisco.= com <mailto:= gsalguei@cisco.com>> wrote:


On Apr 4, 2014, at 2:00 PM, Simon Perreault <simon.perreault@viagenie.ca
<mailto:simon.perreault@viagenie.ca>> wrote:

=A0> Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit :
=A0>> Understood. =A0Nonetheless, even if not a part of STUNbis, it d= oesn't
seem it should be buried in STUNoDTLS. =A0Shall we produce a dedicated
draft for this?
=A0>
=A0> My preference would be for "buried in STUNoDTLS". :) But = I'm open to
arguments for a dedicated draft.

My position is that the ALPN reg is entirely independent of STUNoDTLS,
which is why we considered more contextually relevant for the broader
STUNbis effort. =A0A standalone dedicated ALPN reg doc to point to seems cleaner to me, but I'm open to WG decision on this.

-G


=A0>
=A0> Simon

_______________________________________________
tram mailing list
tram@ietf.org = <mailto: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


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

--f46d0444e9d35d0e4004f68b4149-- From nobody Tue Apr 8 10:52:29 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396DC1A0488 for ; Tue, 8 Apr 2014 10:52:27 -0700 (PDT) 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 ddF9U8CwwdP3 for ; Tue, 8 Apr 2014 10:52:23 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id E5E591A0663 for ; Tue, 8 Apr 2014 10:52:22 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id nPjQ1n0081c6gX85CVsNji; Tue, 08 Apr 2014 17:52:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id nVsN1n00h3ZTu2S3jVsNlY; Tue, 08 Apr 2014 17:52:22 +0000 Message-ID: <53443756.3020806@alum.mit.edu> Date: Tue, 08 Apr 2014 13:52:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> <53441C5D.3070009@alum.mit.edu> In-Reply-To: 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=q20140121; t=1396979542; bh=1WqmxqkeRO1AzPLwYh5rsPcBG8EibK9DXdTfgRUhycg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rT8gvZxVcsnddiZm4oIjIGThQiDNASCQmKpeStL84fDGFREwBGplcPUC0kU64Gjqp qUiGTfdiYgdmdNwIeySBOmX20D2IBwAuV7WT4QA1kMZ16KUezCdT+Co+DLpiDtMk28 lrs1Yhp1OIEc9TyzSibY4KQU8ErtC6e80GTl9oD2NQt1A6h5sLvg7BgWNjeJtA4BnF JQMD+9yfUy2pVKPjOJZwXL/K7qqrg0F+VPfm9x0gu1gxLn+FNYh48eIhx4l8cRelMf Q2nj+5LBSQkdNH40XFL3bKfjEjYrYsGvnxVyyGDG0Z7iZyzqdjeoc5ABmeUa+1bkzp gDtDo1rwOSZrQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OOpIsFNViSBXYyVPBT0OIOKxK4E Cc: "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 17:52:27 -0000 On 4/8/14 1:24 PM, Oleg Moskalenko wrote: > TLS and DTLS are indeed two different protocols with different > characteristics. But in application to TURN, both carry, in most cases, > the same content (the same application-level protocol suite): RTP, RTCP, > SRTP. So I suppose that ALPN will be very similar for both TLS and DTLS. > Then, why not consider them together ? This really wasn't intended as a TRAM-specific comment. It is a comment about ALPN in general. ISTM that people are trying to over-generalize it where it doesn't apply. Note that RTP over TCP is technically a different protocol than RTP over UDP - it requires framing to be added. When you look at where ALPN is defined (draft-friedl-tls-applayerprotoneg) it is intended for use with TLS over TCP. In that context some protocol that is intended for use over an unreliable message oriented transport would be nonsense. Thanks, Paul > On Tue, Apr 8, 2014 at 8:57 AM, Paul Kyzivat > wrote: > > On 4/8/14 1:46 AM, Tirumaleswar Reddy (tireddy) wrote: > > Yup, ALPN will be common for both TLS and DTLS. > > > *Why* would ALPN be common for TLS and DTLS? The characteristics of > those transports are very different, so that it would be very rare > for one higher level protocol to be usable over both. > > Thanks, > Paul > > I see that > http://tools.ietf.org/html/__draft-hutton-rtcweb-nat-__firewall-considerations-03#__section-4.2 > > and > http://tools.ietf.org/html/__draft-thomson-rtcweb-consent-__00#section-3 > > also discuss ALPN. we will need one place holder draft talking > about all > the necessary ALPN identifiers. > > -Tiru > > *From:*tram [mailto:tram-bounces@ietf.org > ] *On Behalf Of *Oleg Moskalenko > *Sent:* Saturday, April 05, 2014 1:47 AM > *To:* Gonzalo Salgueiro (gsalguei) > *Cc:* Simon Perreault; tram@ietf.org > *Subject:* Re: [tram] ALPN Registration [was Re: I-D Action: > > draft-ietf-tram-stun-dtls-01.__txt] > > If ALPN is really independent of DTLS, I see no reason why they > have to > be combined in the draft document that was created solely for > the DTLS > feature introduction for STUNl. > > On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) > > >> wrote: > > > On Apr 4, 2014, at 2:00 PM, Simon Perreault > > >> wrote: > > > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a écrit : > >> Understood. Nonetheless, even if not a part of STUNbis, it > doesn't > seem it should be buried in STUNoDTLS. Shall we produce a dedicated > draft for this? > > > > My preference would be for "buried in STUNoDTLS". :) But I'm > open to > arguments for a dedicated draft. > > My position is that the ALPN reg is entirely independent of > STUNoDTLS, > which is why we considered more contextually relevant for the > broader > STUNbis effort. A standalone dedicated ALPN reg doc to point to > seems > cleaner to me, but I'm open to WG decision on this. > > -G > > > > > > Simon > > _________________________________________________ > 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 nobody Tue Apr 8 13:18:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDED1A026A for ; Tue, 8 Apr 2014 13:18:02 -0700 (PDT) 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 kXeDP7G4xP2A for ; Tue, 8 Apr 2014 13:18:01 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 621AE1A0218 for ; Tue, 8 Apr 2014 13:18:01 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so2085261wiv.12 for ; Tue, 08 Apr 2014 13:18:00 -0700 (PDT) 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=2YlJRLk9XECG9qaJGiQkmJMK6SvOG6U3XmNzrNNYVI4=; b=Irq5tztNXQKjiZCnG/uHtOGICjgU8lMeuRWrLu2XJcr7/XQh1INs1S+G11CFQSDwb/ Et2wwDD684a63CCmSpcvGB04LvmIdHngfA9ls+gnI6LSBxDpnmrGdTU0dFGBsS+vN0C1 z54ESYw2ufW/XjGwAYjc3BRsLoPAMgRMM2LY77Tjhq4jQ2pBw9Noikhsd+GjzuCbRDnD aZz+NlbjsEp5V5K4L5BIItqAPx95j/NuYZ/5j3oAR1sSgaukRvINc1HDtamUET2qDMIF UvRhH/0Nhlb0/1XCtDne3vKciOktyFvcYiguY7s+ylpd4tKTxpnG1bLsu7VG1H7V2nNz Eg/A== MIME-Version: 1.0 X-Received: by 10.194.86.7 with SMTP id l7mr5539438wjz.37.1396988280780; Tue, 08 Apr 2014 13:18:00 -0700 (PDT) Received: by 10.194.9.67 with HTTP; Tue, 8 Apr 2014 13:18:00 -0700 (PDT) In-Reply-To: <53443756.3020806@alum.mit.edu> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> <53441C5D.3070009@alum.mit.edu> <53443756.3020806@alum.mit.edu> Date: Tue, 8 Apr 2014 13:18:00 -0700 Message-ID: From: Oleg Moskalenko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e0102e4f03b3cb004f68daec8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/LbhOlJX0wOSBfFcleGTnTl2S0UU Cc: "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 20:18:03 -0000 --089e0102e4f03b3cb004f68daec8 Content-Type: text/plain; charset=ISO-8859-1 please see inside On Tue, Apr 8, 2014 at 10:52 AM, Paul Kyzivat wrote: > On 4/8/14 1:24 PM, Oleg Moskalenko wrote: > >> TLS and DTLS are indeed two different protocols with different >> characteristics. But in application to TURN, both carry, in most cases, >> the same content (the same application-level protocol suite): RTP, RTCP, >> SRTP. So I suppose that ALPN will be very similar for both TLS and DTLS. >> Then, why not consider them together ? >> > > This really wasn't intended as a TRAM-specific comment. > It is a comment about ALPN in general. ISTM that people are trying to > over-generalize it where it doesn't apply. > OK. We were discussing it in TRAM context. > > Note that RTP over TCP is technically a different protocol than RTP over > UDP - it requires framing to be added. > STUN protocol is providing that framing, already. Both UDP TURN and TCP TURN are using the same "framing" format. So, in TRAM context, there is no difference between RTP-inside-TURN-inside-TLS and RTP-inside-TURN-inside-DTLS (if we are not talking about RFC 6062 TCP TURN). > > When you look at where ALPN is defined (draft-friedl-tls-applayerprotoneg) > it is intended for use with TLS over TCP. In that context some protocol > that is intended for use over an unreliable message oriented transport > would be nonsense. > Well, the reality is that RTP is used in TCP TURN quite often and this is part of WebRTC. So I am not sure that there is anything wrong in using ALPN with DTLS-TURN. Thanks, Oleg --089e0102e4f03b3cb004f68daec8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
please see inside

<= br>
On Tue, Apr 8, 2014 at 10:52 AM, Paul Kyzivat= <pkyzivat@alum.mit.edu> wrote:
On 4/8/14 1:24 PM, Oleg Mosk= alenko wrote:
TLS and DTLS are indeed two different protocols with different
characteristics. But in application to TURN, both carry, in most cases,
the same content (the same application-level protocol suite): RTP, RTCP, SRTP. So I suppose that ALPN will be very similar for both TLS and DTLS. Then, why not consider them together ?

This really wasn't intended as a TRAM-specific comment.
It is a comment about ALPN in general. ISTM that people are trying to over-= generalize it where it doesn't apply.

OK. We were discussing it in TRAM context.
=A0

Note that RTP over TCP is technically a different protocol than RTP over UD= P - it requires framing to be added.

ST= UN protocol is providing that framing, already. Both UDP TURN and TCP=A0 TU= RN are using the same "framing" format. So, in TRAM context, ther= e is no difference between RTP-inside-TURN-inside-TLS and RTP-inside-TURN-i= nside-DTLS (if we are not talking about RFC 6062 TCP TURN).
=A0

When you look at where ALPN is defined (draft-friedl-tls-applayerpro= toneg) it is intended for use with TLS over TCP. In that context some proto= col that is intended for use over an unreliable message oriented transport = would be nonsense.

Well, the reality is that RTP is used in T= CP TURN quite often and this is part of WebRTC. So I am not sure that there= is anything wrong in using ALPN with DTLS-TURN.
=A0
Thanks,
Oleg

--089e0102e4f03b3cb004f68daec8-- From nobody Tue Apr 8 13:33:01 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373241A02A7 for ; Tue, 8 Apr 2014 13:33:00 -0700 (PDT) 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 j7CLulcx72fG for ; Tue, 8 Apr 2014 13:32:59 -0700 (PDT) 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 514671A0218 for ; Tue, 8 Apr 2014 13:32:59 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id nXfZ1n0021vXlb853YYzpG; Tue, 08 Apr 2014 20:32:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id nYYy1n0153ZTu2S3dYYyXb; Tue, 08 Apr 2014 20:32:59 +0000 Message-ID: <53445CFA.9050303@alum.mit.edu> Date: Tue, 08 Apr 2014 16:32:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> <53441C5D.3070009@alum.mit.edu> <53443756.3020806@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=q20140121; t=1396989179; bh=7s62R9R3R7v+zz+amfKjEeayocdfTUHDSNsr4eCMoRU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GUQEJZ2iSdFvmIm1RXeMNPTOrZE3O0nG3R50gAFLpz1M1m/5UKaPXXvvU1BYw+CI7 3PSyl/m0KZh99mLQoejLtrD4HxbYvrfX0Y8uEauVmZKiLTaWXzepya/hzZyXg/QNgb SU6W8COohoBCsXj+N62cPr15m+KAU9qrqYTSlI2TEL0cO6czgGG+DZK8B7qWVzxtZ8 4QK0yJSJR0ocLxc6zAce63rQJ52+6YBKf0bVPDLvfTnnZoyheAtlrP4KgATrAjvEse PvJUMYVAxDIdvgYyWJxzgMDq8WklWYWCYsWwLSAkg+dAmqmMA117xm5jo9/gywOPSU 9mzv0sXN2jgsw== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lTFe-1s9kOeM37SX1EE2R0kYUqo Cc: "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 20:33:00 -0000 On 4/8/14 4:18 PM, Oleg Moskalenko wrote: > please see inside > > > On Tue, Apr 8, 2014 at 10:52 AM, Paul Kyzivat > wrote: > > On 4/8/14 1:24 PM, Oleg Moskalenko wrote: > > TLS and DTLS are indeed two different protocols with different > characteristics. But in application to TURN, both carry, in most > cases, > the same content (the same application-level protocol suite): > RTP, RTCP, > SRTP. So I suppose that ALPN will be very similar for both TLS > and DTLS. > Then, why not consider them together ? > > > This really wasn't intended as a TRAM-specific comment. > It is a comment about ALPN in general. ISTM that people are trying > to over-generalize it where it doesn't apply. > > > OK. We were discussing it in TRAM context. > > > Note that RTP over TCP is technically a different protocol than RTP > over UDP - it requires framing to be added. > > > STUN protocol is providing that framing, already. Both UDP TURN and TCP > TURN are using the same "framing" format. So, in TRAM context, there is > no difference between RTP-inside-TURN-inside-TLS and > RTP-inside-TURN-inside-DTLS (if we are not talking about RFC 6062 TCP TURN). > > > When you look at where ALPN is defined > (draft-friedl-tls-__applayerprotoneg) it is intended for use with > TLS over TCP. In that context some protocol that is intended for use > over an unreliable message oriented transport would be nonsense. > > > Well, the reality is that RTP is used in TCP TURN quite often and this > is part of WebRTC. So I am not sure that there is anything wrong in > using ALPN with DTLS-TURN. I agree that this seems to work fine for TURN - *if* a common ALPN registry makes sense over all transports. I'll pursue my issues in a more appropriate forum. Thanks, Paul From nobody Wed Apr 9 04:03:26 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744871A0222 for ; Wed, 9 Apr 2014 04:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 17EmclWbTJIS for ; Wed, 9 Apr 2014 04:03:21 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2088C1A00CF for ; Wed, 9 Apr 2014 04:03:17 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 24D2A23F05EA; Wed, 9 Apr 2014 13:03:16 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.60]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 13:03:15 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , Oleg Moskalenko Thread-Topic: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: AQHPU2en6AY8ZFaHYEKBllLCRGFGsJsICx4AgAEShGA= Date: Wed, 9 Apr 2014 11:03:15 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17D6C9A0@MCHP04MSX.global-ad.net> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> <53441C5D.3070009@alum.mit.edu> <53443756.3020806@alum.mit.edu> <53445CFA.9050303@alum.mit.edu> In-Reply-To: <53445CFA.9050303@alum.mit.edu> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xa9Hg6xAXuI2i6e5XzsaMfqgMCw Cc: "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:03:23 -0000 Looks like the issue of including DTLS in the ALPN draft (http://tools.ietf= .org/html/draft-ietf-tls-applayerprotoneg-05) has been discussed in TLS (Se= e http://www.ietf.org/mail-archive/web/tls/current/msg11534.html) and hopef= ully some clarification on use of ALPN will be added to the next update. I assume that it would be necessary to use different ALPN identifiers if on= ly because it will probably be necessary to point to two different RFC's fo= r STUN/TURN over TLS and DTLS. Andy > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 08 April 2014 21:33 > To: Oleg Moskalenko > Cc: tram@ietf.org > Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf- > tram-stun-dtls-01.txt] >=20 > On 4/8/14 4:18 PM, Oleg Moskalenko wrote: > > please see inside > > > > > > On Tue, Apr 8, 2014 at 10:52 AM, Paul Kyzivat > > wrote: > > > > On 4/8/14 1:24 PM, Oleg Moskalenko wrote: > > > > TLS and DTLS are indeed two different protocols with > different > > characteristics. But in application to TURN, both carry, in > most > > cases, > > the same content (the same application-level protocol suite): > > RTP, RTCP, > > SRTP. So I suppose that ALPN will be very similar for both > TLS > > and DTLS. > > Then, why not consider them together ? > > > > > > This really wasn't intended as a TRAM-specific comment. > > It is a comment about ALPN in general. ISTM that people are > trying > > to over-generalize it where it doesn't apply. > > > > > > OK. We were discussing it in TRAM context. > > > > > > Note that RTP over TCP is technically a different protocol than > RTP > > over UDP - it requires framing to be added. > > > > > > STUN protocol is providing that framing, already. Both UDP TURN and > TCP > > TURN are using the same "framing" format. So, in TRAM context, there > is > > no difference between RTP-inside-TURN-inside-TLS and > > RTP-inside-TURN-inside-DTLS (if we are not talking about RFC 6062 TCP > TURN). > > > > > > When you look at where ALPN is defined > > (draft-friedl-tls-__applayerprotoneg) it is intended for use with > > TLS over TCP. In that context some protocol that is intended for > use > > over an unreliable message oriented transport would be nonsense. > > > > > > Well, the reality is that RTP is used in TCP TURN quite often and > this > > is part of WebRTC. So I am not sure that there is anything wrong in > > using ALPN with DTLS-TURN. >=20 > I agree that this seems to work fine for TURN - *if* a common ALPN > registry makes sense over all transports. >=20 > I'll pursue my issues in a more appropriate forum. >=20 > Thanks, > Paul >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Apr 9 05:55:00 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F50D1A0285 for ; Wed, 9 Apr 2014 05:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 VTs2bVyeV2zb for ; Wed, 9 Apr 2014 05:54:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 06A8F1A012D for ; Wed, 9 Apr 2014 05:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3851; q=dns/txt; s=iport; t=1397048095; x=1398257695; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I1eKSmQefYvJVijg51ZJ9+hbdP5NgXbB0gbNPIjhODw=; b=Np+huuyRyMeFAzz24Qop0CaY5j9gSV6TXFMv9g1eCOyG2+48anWabpWS Ijud+AkpD5737IyqThz6Y+obezFIxjy9im459/EVPIVZKyeLFKGZaz9bm 2jEEUNJQuODPYOuVdrQBxV0QAWM9dWILmIXythf3U3M2n0+ykhPirY9NT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFADxCRVOtJV2a/2dsb2JhbAA/Gg6CeDtRBrxWhzWBIBZ0giUBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCAGHcwgFNssuF44bAQEeMQcGgx6BFASaE4tBhUyBcX9Aeng5 X-IronPort-AV: E=Sophos;i="4.97,826,1389744000"; d="scan'208";a="316374001" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 09 Apr 2014 12:54:54 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s39Css6q000374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Apr 2014 12:54:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.98]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 9 Apr 2014 07:54:53 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Hutton, Andrew" , Paul Kyzivat , Oleg Moskalenko Thread-Topic: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: AQHPT+yZvUynsYQs1k6AEQn6+QFgjJsByeWAgABJJ4CAAAB2AIAAAnsAgAAjvYCABPpwUIABBjyAgAAYVwCAAAfRAIAAKLAAgAAELwCAAPMngP//yi0A Date: Wed, 9 Apr 2014 12:54:53 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24312457@xmb-rcd-x10.cisco.com> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <913383AAA69FF945B8F946018B75898A24310130@xmb-rcd-x10.cisco.com> <53441C5D.3070009@alum.mit.edu> <53443756.3020806@alum.mit.edu> <53445CFA.9050303@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17D6C9A0@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17D6C9A0@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_bFYvr6DHKNnXYE3mR3otZxpoAE Cc: "tram@ietf.org" Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:54:59 -0000 ALPN can also be sent for DTLS, it's only a doc mistake and errata for that= is raised in http://www.rfc-editor.org/errata_search.php?rfc=3D6347&eid=3D= 3917 -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew > Sent: Wednesday, April 09, 2014 4:33 PM > To: Paul Kyzivat; Oleg Moskalenko > Cc: tram@ietf.org > Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tra= m-stun- > dtls-01.txt] >=20 > Looks like the issue of including DTLS in the ALPN draft > (http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05) has been > discussed in TLS (See http://www.ietf.org/mail- > archive/web/tls/current/msg11534.html) and hopefully some clarification o= n > use of ALPN will be added to the next update. >=20 > I assume that it would be necessary to use different ALPN identifiers if = only > because it will probably be necessary to point to two different RFC's for > STUN/TURN over TLS and DTLS. >=20 > Andy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 08 April 2014 21:33 > > To: Oleg Moskalenko > > Cc: tram@ietf.org > > Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf- > > tram-stun-dtls-01.txt] > > > > On 4/8/14 4:18 PM, Oleg Moskalenko wrote: > > > please see inside > > > > > > > > > On Tue, Apr 8, 2014 at 10:52 AM, Paul Kyzivat > > > wrote: > > > > > > On 4/8/14 1:24 PM, Oleg Moskalenko wrote: > > > > > > TLS and DTLS are indeed two different protocols with > > different > > > characteristics. But in application to TURN, both carry, in > > most > > > cases, > > > the same content (the same application-level protocol suite): > > > RTP, RTCP, > > > SRTP. So I suppose that ALPN will be very similar for both > > TLS > > > and DTLS. > > > Then, why not consider them together ? > > > > > > > > > This really wasn't intended as a TRAM-specific comment. > > > It is a comment about ALPN in general. ISTM that people are > > trying > > > to over-generalize it where it doesn't apply. > > > > > > > > > OK. We were discussing it in TRAM context. > > > > > > > > > Note that RTP over TCP is technically a different protocol than > > RTP > > > over UDP - it requires framing to be added. > > > > > > > > > STUN protocol is providing that framing, already. Both UDP TURN and > > TCP > > > TURN are using the same "framing" format. So, in TRAM context, there > > is > > > no difference between RTP-inside-TURN-inside-TLS and > > > RTP-inside-TURN-inside-DTLS (if we are not talking about RFC 6062 > > > TCP > > TURN). > > > > > > > > > When you look at where ALPN is defined > > > (draft-friedl-tls-__applayerprotoneg) it is intended for use with > > > TLS over TCP. In that context some protocol that is intended for > > use > > > over an unreliable message oriented transport would be nonsense. > > > > > > > > > Well, the reality is that RTP is used in TCP TURN quite often and > > this > > > is part of WebRTC. So I am not sure that there is anything wrong in > > > using ALPN with DTLS-TURN. > > > > I agree that this seems to work fine for TURN - *if* a common ALPN > > registry makes sense over all transports. > > > > I'll pursue my issues in a more appropriate forum. > > > > Thanks, > > Paul > > > > _______________________________________________ > > 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 nobody Thu Apr 10 03:26:45 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1BD1A01FB for ; Thu, 10 Apr 2014 03:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.073 X-Spam-Level: X-Spam-Status: No, score=-7.073 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 2TdmDmmKJ-hm for ; Thu, 10 Apr 2014 03:26:39 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3E01A01F6 for ; Thu, 10 Apr 2014 03:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6782; q=dns/txt; s=iport; t=1397125598; x=1398335198; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=bJZUCHeNLqDlPZsmOrzcZlD66ywfjyh9CjL094G0bOc=; b=ZWkkYf+IV+uOy18GIne6lJaq9v3XAPeNNpmB/DM9G3XBVL62XaIlUfZu 3dS/fzfQAofoiNZkQZsZ8DICrGkfpaHlhFYj5OGgCD6jbd9cl+OWOD1k8 W6q/G4ZZKzxRCYtfjV7V08LI25FRbsGqom5Q+kVZFxlL+2HA+YKKHrTKD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAJ1wRlOtJV2Z/2dsb2JhbABagwY7V7xzhzWBIxZ0giUBAQEEAQEBGgpHFwYBCBEEAQEBCg4MAy4LFAkJAQQBEgiHdA2rX4IfnmMXjiMYPhKDDIEUBIkjkHCRDYMwgWpB X-IronPort-AV: E=Sophos;i="4.97,833,1389744000"; d="scan'208";a="34589072" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 10 Apr 2014 10:26:38 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3AAQcUx005729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Apr 2014 10:26:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.98]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 05:26:37 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] STUN hash agility Thread-Index: Ac9Up1VwvOjmc8T8SwWmko2VoEAY3g== Date: Thu, 10 Apr 2014 10:26:36 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A243131E2@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.181] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ICMZf8w8ySl5j1vbnlBhVVm8APU Subject: Re: [tram] STUN hash agility 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, 10 Apr 2014 10:26:44 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Tuesday, April 08, 2014 12:41 AM > To: tram@ietf.org > Subject: Re: [tram] STUN hash agility >=20 > Isn't that problem more in the category of 3rd party auth improvements th= an > hash agility? > Or are you suggesting that the hashing mechanism to be used on the > authentication information could make a difference in terms of whether or= not > it was viewed as violating that policy ? Though 3rd party authorization does not have the problem of hash agility, I= am not sure if that means first party authentication can be removed. TURN = servers provided by Application servers may want to only use 3rd party auth= orization. But first party authentication may be required for Enterprise us= e cases. For example considering the requirement discussed in http://tools.= ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5= .1 where it is mandatory to for the Enterprise to use TURN for all external= RTCWEB communication. The auditing policy requires TURN server should be a= ware of endpoints username/realm for logging purpose. If the Enterprise I.T decides to go with a cloud vendor either offering TUR= N servers or decides to setup it's TURN servers in a public cloud. The auth= entication mechanism requires that either the TURN server should know the u= ser credentials or alternatively gets the credentials from the AD server de= ployed in the Enterprise Data Center. But both mechanisms may not acceptabl= e since it requires the credentials to be stored outside the Enterprise pre= mises. The policy violations with the current authentication mechanism wou= ld be that: * Data is extremely sensitive and the management cannot risk hosting it on = public infrastructure but at the same time wants to leverage cloud services * Local and national laws prohibit data from leaving the country the compan= y is domiciled in * The business is not confident of entrusting data to a third party -Tiru >=20 > --Brandon >=20 > On 04/07/2014 02:33 PM, Tirumaleswar Reddy (tireddy) wrote: > > The other point that we missed to discuss is that if Enterprise wants t= o > leverage the services of cloud (for e.g. Hybrid cloud) for deploying TURN= servers. > Enterprise information security policy may not permit credentials to be s= tored > outside it's domain. > > > > Cheers, > > -Tiru > > > >> -----Original Message----- > >> From: Tirumaleswar Reddy (tireddy) > >> Sent: Tuesday, April 01, 2014 5:45 PM > >> To: 'Simon Perreault'; Oleg Moskalenko; Jonathan Lennox > >> Cc: tram@ietf.org > >> Subject: RE: [tram] STUN hash agility > >> > >>> -----Original Message----- > >>> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > >>> Sent: Friday, March 28, 2014 6:17 PM > >>> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko; Jonathan Lennox > >>> Cc: tram@ietf.org > >>> Subject: Re: [tram] STUN hash agility > >>> > >>> Oooooh! I love playing the devil's advocate... :) > >> > >> :) > >> > >>> > >>> Le 2014-03-28 05:16, Tirumaleswar Reddy (tireddy) a =E9crit : > >>>> 1)TURN Server has to maintain the {username/realm/password} > >>>> database just like the AD server which is an overhead. > >>> > >>> Are you assuming that the TURN server cannot query the AD server > >>> instead of maintaining a duplicate database ? > >> > >> TURN server can query the AD server. But this will be not be the > >> typical request/response used, in this case the request must contain > >> (username, realm) asking for the password. > >> > >>> > >>> In any case, database replication is easy and well understood. You > >>> need to have *lots* of accounts for e.g. dead-simple MySQL > >>> replication to not be sufficient. > >> > >> Or the TURN server can establish connection with remote RDMS server > >> and send query to get the password. > >> > >>> > >>>> 2)In a large Enterprise Network (for e.g. consider a large service > >>>> company) where NNN number of new users join, MMM users leave every > >> day. > >>>> It seems difficult to manage this credential database on the TURN > >>>> server to be in sync with the AD. > >>> > >>> Really? MySQL replication (for example) is dead simple. > >>> > >>>> 3)If each branch office in an large enterprise network wants to > >>>> deploy TURN servers, then the cost of TURN server includes > >>>> additional storage space and operational issues which may be a > >>>> concern of the I.T. > >>> > >>> I doubt this very much. You would need *lots* of user accounts for > >>> the password database to not fit on any regular-sized hard drive. > >>> > >>> About operations: once again, database replication is well > >>> understood and very common. > >> > >> Database replication will work but it's an overhead in the above use > >> case. In service based companies, where onboarding/off-boarding of > >> users on daily basis is frequent, this would call for frequent > >> database replication. If branch offices want TURN server to be > >> co-located with a router, it may not even have hard- drive to store > >> this info. With the current limitation, software upgrade of the > >> router to support TURN server will not be sufficient. I.T will also ha= ve to > purchase routers which come up hard drive. > >> > >> Further a small branch/sales office of an Enterprise network may have > >> only few hundred users in that site, it's an over-head to replicate > >> the credentials of the entire org to this small site. > >> > >>> > >>>> 4)AD server maintained in the Data Center usually has better > >>>> physical security than branch offices - what if someone breaks into > >>>> the branch office and steals all the username + password ? (I am > >>>> assuming the username, password are the same credentials used to > >>>> access other critical enterprise resources) > >>> > >>> Now this I totally buy. We need something better than > >>> MD5(username:realm:password). > >> > >> Cheers, > >> -Tiru > >> > >>> > >>> 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 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Apr 10 05:58:47 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2633A1A026B for ; Thu, 10 Apr 2014 05:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 wQlLNrCbAp_E for ; Thu, 10 Apr 2014 05:58:40 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2441A010E for ; Thu, 10 Apr 2014 05:58:40 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 52EA528566 for ; Thu, 10 Apr 2014 12:58:39 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 3BB5E28563 for ; Thu, 10 Apr 2014 12:58:39 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id E3F3DFE070 for ; Thu, 10 Apr 2014 12:58:38 +0000 (GMT) Message-ID: <5346957B.1080500@akamai.com> Date: Thu, 10 Apr 2014 08:58:35 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <534694DB.3010504@akamai.com> In-Reply-To: <534694DB.3010504@akamai.com> X-Forwarded-Message-Id: <534694DB.3010504@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/i1-ivR1-wJ6WzUoHITpzJ_iCQpc Subject: Re: [tram] STUN hash agility 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, 10 Apr 2014 12:58:45 -0000 I'm not sure this answers my question, so perhaps I was unclear. What is the relationship between this corporate security policy and discussion of hash agility? The only possible relevance that I can see is the question of whether storing the hashed user:realm:passwd counts as storing the credentials. With a good enough hash algorithm, I think the answer is "no", and so the discussion of hash agility needs to ensure that the algorithm is good enough. If the credentials are not allowed to even be transmitted to the TURN server, then the enterprise should treat the TURN server as a 3rd party and use the 3rd party mechanism. --Brandon On 04/10/2014 06:26 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Tuesday, April 08, 2014 12:41 AM >> To: tram@ietf.org >> Subject: Re: [tram] STUN hash agility >> >> Isn't that problem more in the category of 3rd party auth improvements than >> hash agility? >> Or are you suggesting that the hashing mechanism to be used on the >> authentication information could make a difference in terms of whether or not >> it was viewed as violating that policy ? > > Though 3rd party authorization does not have the problem of hash agility, I am not sure if that means first party authentication can be removed. TURN servers provided by Application servers may want to only use 3rd party authorization. But first party authentication may be required for Enterprise use cases. For example considering the requirement discussed in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.1 where it is mandatory to for the Enterprise to use TURN for all external RTCWEB communication. The auditing policy requires TURN server should be aware of endpoints username/realm for logging purpose. > > If the Enterprise I.T decides to go with a cloud vendor either offering TURN servers or decides to setup it's TURN servers in a public cloud. The authentication mechanism requires that either the TURN server should know the user credentials or alternatively gets the credentials from the AD server deployed in the Enterprise Data Center. But both mechanisms may not acceptable since it requires the credentials to be stored outside the Enterprise premises. The policy violations with the current authentication mechanism would be that: > > * Data is extremely sensitive and the management cannot risk hosting it on public infrastructure but at the same time wants to leverage cloud services > * Local and national laws prohibit data from leaving the country the company is domiciled in > * The business is not confident of entrusting data to a third party > > -Tiru > >> >> --Brandon >> >> On 04/07/2014 02:33 PM, Tirumaleswar Reddy (tireddy) wrote: >>> The other point that we missed to discuss is that if Enterprise wants to >> leverage the services of cloud (for e.g. Hybrid cloud) for deploying TURN servers. >> Enterprise information security policy may not permit credentials to be stored >> outside it's domain. >>> >>> Cheers, >>> -Tiru >>> >>>> -----Original Message----- >>>> From: Tirumaleswar Reddy (tireddy) >>>> Sent: Tuesday, April 01, 2014 5:45 PM >>>> To: 'Simon Perreault'; Oleg Moskalenko; Jonathan Lennox >>>> Cc: tram@ietf.org >>>> Subject: RE: [tram] STUN hash agility >>>> >>>>> -----Original Message----- >>>>> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >>>>> Sent: Friday, March 28, 2014 6:17 PM >>>>> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko; Jonathan Lennox >>>>> Cc: tram@ietf.org >>>>> Subject: Re: [tram] STUN hash agility >>>>> >>>>> Oooooh! I love playing the devil's advocate... :) >>>> >>>> :) >>>> >>>>> >>>>> Le 2014-03-28 05:16, Tirumaleswar Reddy (tireddy) a écrit : >>>>>> 1)TURN Server has to maintain the {username/realm/password} >>>>>> database just like the AD server which is an overhead. >>>>> >>>>> Are you assuming that the TURN server cannot query the AD server >>>>> instead of maintaining a duplicate database ? >>>> >>>> TURN server can query the AD server. But this will be not be the >>>> typical request/response used, in this case the request must contain >>>> (username, realm) asking for the password. >>>> >>>>> >>>>> In any case, database replication is easy and well understood. You >>>>> need to have *lots* of accounts for e.g. dead-simple MySQL >>>>> replication to not be sufficient. >>>> >>>> Or the TURN server can establish connection with remote RDMS server >>>> and send query to get the password. >>>> >>>>> >>>>>> 2)In a large Enterprise Network (for e.g. consider a large service >>>>>> company) where NNN number of new users join, MMM users leave every >>>> day. >>>>>> It seems difficult to manage this credential database on the TURN >>>>>> server to be in sync with the AD. >>>>> >>>>> Really? MySQL replication (for example) is dead simple. >>>>> >>>>>> 3)If each branch office in an large enterprise network wants to >>>>>> deploy TURN servers, then the cost of TURN server includes >>>>>> additional storage space and operational issues which may be a >>>>>> concern of the I.T. >>>>> >>>>> I doubt this very much. You would need *lots* of user accounts for >>>>> the password database to not fit on any regular-sized hard drive. >>>>> >>>>> About operations: once again, database replication is well >>>>> understood and very common. >>>> >>>> Database replication will work but it's an overhead in the above use >>>> case. In service based companies, where onboarding/off-boarding of >>>> users on daily basis is frequent, this would call for frequent >>>> database replication. If branch offices want TURN server to be >>>> co-located with a router, it may not even have hard- drive to store >>>> this info. With the current limitation, software upgrade of the >>>> router to support TURN server will not be sufficient. I.T will also have to >> purchase routers which come up hard drive. >>>> >>>> Further a small branch/sales office of an Enterprise network may have >>>> only few hundred users in that site, it's an over-head to replicate >>>> the credentials of the entire org to this small site. >>>> >>>>> >>>>>> 4)AD server maintained in the Data Center usually has better >>>>>> physical security than branch offices - what if someone breaks into >>>>>> the branch office and steals all the username + password ? (I am >>>>>> assuming the username, password are the same credentials used to >>>>>> access other critical enterprise resources) >>>>> >>>>> Now this I totally buy. We need something better than >>>>> MD5(username:realm:password). >>>> >>>> Cheers, >>>> -Tiru >>>> >>>>> >>>>> 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 >>> >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> 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 > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Apr 11 05:19:05 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDD91A067A for ; Fri, 11 Apr 2014 05:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 ctnsqYcTfBh5 for ; Fri, 11 Apr 2014 05:18:57 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 551A61A0235 for ; Fri, 11 Apr 2014 05:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8825; q=dns/txt; s=iport; t=1397218735; x=1398428335; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=mLreB8BQ3LFGca4ZT0k6Q6GCw/OEih4fBmwJ3f7Yi/4=; b=Jlsp7R7RyWVgx91ZoIY0RkZZ3UJe9h2TdvlMVUVpOTQsahOYTmOHnia4 acDTyiNsXe30SK+mSKzYEeanqkiYjm0plLlZD2mddmCR+XdCdHsvDcTF5 xFRmgforDZZah4nXEM0nVjd/E0xA5XScTY7Tu4S6B8TIvpB7AWQd3Y0va k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAM7cR1OtJV2Z/2dsb2JhbABZgwY7V70VhzWBGxZ0giUBAQEEAQEBGgpHBBMGAQgRBAEBAQoODAMuCxQJCQEEARIIh3QNqzuCH542F44jGD4SgwyBFASJI5BykQ2DMYFqQQ X-IronPort-AV: E=Sophos;i="4.97,841,1389744000"; d="scan'208";a="34950858" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 11 Apr 2014 12:18:54 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3BCIt6b029641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 12:18:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.98]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 07:18:54 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] STUN hash agility Thread-Index: Ac9VgDGAIuubTjLPQi6Emac6bsbs7g== Date: Fri, 11 Apr 2014 12:18:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24313D19@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.193] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/dL0BP8YjFfGqdy0E8QF7PSdRio0 Subject: Re: [tram] STUN hash agility 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, 11 Apr 2014 12:19:02 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Thursday, April 10, 2014 6:29 PM > To: tram@ietf.org > Subject: Re: [tram] STUN hash agility >=20 > I'm not sure this answers my question, so perhaps I was unclear. >=20 > What is the relationship between this corporate security policy and > discussion of hash agility? The only possible relevance that I can see > is the question of whether storing the hashed user:realm:passwd counts > as storing the credentials. With a good enough hash algorithm, I think > the answer is "no", and so the discussion of hash agility needs to > ensure that the algorithm is good enough. >=20 > If the credentials are not allowed to even be transmitted to the TURN > server, then the enterprise should treat the TURN server as a 3rd party > and use the 3rd party mechanism. I am only trying to say that Data at Rest in public cloud may have security= implications compared to Data on transit and I see that other protocols th= at use first party authentication but do not have limitation of storing the= credentials locally.=20 -Tiru >=20 > --Brandon >=20 > On 04/10/2014 06:26 AM, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- > >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon William= s > >> Sent: Tuesday, April 08, 2014 12:41 AM > >> To: tram@ietf.org > >> Subject: Re: [tram] STUN hash agility > >> > >> Isn't that problem more in the category of 3rd party auth improvements= than > >> hash agility? > >> Or are you suggesting that the hashing mechanism to be used on the > >> authentication information could make a difference in terms of whether= or > not > >> it was viewed as violating that policy ? > > > > Though 3rd party authorization does not have the problem of hash agilit= y, I am > not sure if that means first party authentication can be removed. TURN se= rvers > provided by Application servers may want to only use 3rd party authorizat= ion. > But first party authentication may be required for Enterprise use cases. = For > example considering the requirement discussed in > http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements- > 14#section-3.3.5.1 where it is mandatory to for the Enterprise to use TUR= N for > all external RTCWEB communication. The auditing policy requires TURN serv= er > should be aware of endpoints username/realm for logging purpose. > > > > If the Enterprise I.T decides to go with a cloud vendor either offering= TURN > servers or decides to setup it's TURN servers in a public cloud. The > authentication mechanism requires that either the TURN server should know= the > user credentials or alternatively gets the credentials from the AD server > deployed in the Enterprise Data Center. But both mechanisms may not > acceptable since it requires the credentials to be stored outside the Ent= erprise > premises. The policy violations with the current authentication mechanis= m > would be that: > > > > * Data is extremely sensitive and the management cannot risk hosting it= on > public infrastructure but at the same time wants to leverage cloud servic= es > > * Local and national laws prohibit data from leaving the country the co= mpany > is domiciled in > > * The business is not confident of entrusting data to a third party > > > > -Tiru > > > >> > >> --Brandon > >> > >> On 04/07/2014 02:33 PM, Tirumaleswar Reddy (tireddy) wrote: > >>> The other point that we missed to discuss is that if Enterprise wants= to > >> leverage the services of cloud (for e.g. Hybrid cloud) for deploying T= URN > servers. > >> Enterprise information security policy may not permit credentials to b= e stored > >> outside it's domain. > >>> > >>> Cheers, > >>> -Tiru > >>> > >>>> -----Original Message----- > >>>> From: Tirumaleswar Reddy (tireddy) > >>>> Sent: Tuesday, April 01, 2014 5:45 PM > >>>> To: 'Simon Perreault'; Oleg Moskalenko; Jonathan Lennox > >>>> Cc: tram@ietf.org > >>>> Subject: RE: [tram] STUN hash agility > >>>> > >>>>> -----Original Message----- > >>>>> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > >>>>> Sent: Friday, March 28, 2014 6:17 PM > >>>>> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko; Jonathan Lennox > >>>>> Cc: tram@ietf.org > >>>>> Subject: Re: [tram] STUN hash agility > >>>>> > >>>>> Oooooh! I love playing the devil's advocate... :) > >>>> > >>>> :) > >>>> > >>>>> > >>>>> Le 2014-03-28 05:16, Tirumaleswar Reddy (tireddy) a =E9crit : > >>>>>> 1)TURN Server has to maintain the {username/realm/password} > >>>>>> database just like the AD server which is an overhead. > >>>>> > >>>>> Are you assuming that the TURN server cannot query the AD server > >>>>> instead of maintaining a duplicate database ? > >>>> > >>>> TURN server can query the AD server. But this will be not be the > >>>> typical request/response used, in this case the request must contain > >>>> (username, realm) asking for the password. > >>>> > >>>>> > >>>>> In any case, database replication is easy and well understood. You > >>>>> need to have *lots* of accounts for e.g. dead-simple MySQL > >>>>> replication to not be sufficient. > >>>> > >>>> Or the TURN server can establish connection with remote RDMS server > >>>> and send query to get the password. > >>>> > >>>>> > >>>>>> 2)In a large Enterprise Network (for e.g. consider a large service > >>>>>> company) where NNN number of new users join, MMM users leave > every > >>>> day. > >>>>>> It seems difficult to manage this credential database on the TURN > >>>>>> server to be in sync with the AD. > >>>>> > >>>>> Really? MySQL replication (for example) is dead simple. > >>>>> > >>>>>> 3)If each branch office in an large enterprise network wants to > >>>>>> deploy TURN servers, then the cost of TURN server includes > >>>>>> additional storage space and operational issues which may be a > >>>>>> concern of the I.T. > >>>>> > >>>>> I doubt this very much. You would need *lots* of user accounts for > >>>>> the password database to not fit on any regular-sized hard drive. > >>>>> > >>>>> About operations: once again, database replication is well > >>>>> understood and very common. > >>>> > >>>> Database replication will work but it's an overhead in the above use > >>>> case. In service based companies, where onboarding/off-boarding of > >>>> users on daily basis is frequent, this would call for frequent > >>>> database replication. If branch offices want TURN server to be > >>>> co-located with a router, it may not even have hard- drive to store > >>>> this info. With the current limitation, software upgrade of the > >>>> router to support TURN server will not be sufficient. I.T will also = have to > >> purchase routers which come up hard drive. > >>>> > >>>> Further a small branch/sales office of an Enterprise network may hav= e > >>>> only few hundred users in that site, it's an over-head to replicate > >>>> the credentials of the entire org to this small site. > >>>> > >>>>> > >>>>>> 4)AD server maintained in the Data Center usually has better > >>>>>> physical security than branch offices - what if someone breaks int= o > >>>>>> the branch office and steals all the username + password ? (I am > >>>>>> assuming the username, password are the same credentials used to > >>>>>> access other critical enterprise resources) > >>>>> > >>>>> Now this I totally buy. We need something better than > >>>>> MD5(username:realm:password). > >>>> > >>>> Cheers, > >>>> -Tiru > >>>> > >>>>> > >>>>> 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 > >>> > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging Products > >> Engineering; Akamai Technologies Inc. > >> > >> _______________________________________________ > >> 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 > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Apr 18 07:10:32 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5121A0177 for ; Fri, 18 Apr 2014 07:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 nMct0pKpBzi1 for ; Fri, 18 Apr 2014 07:10:26 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 929701A02B4 for ; Fri, 18 Apr 2014 07:10:26 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id uy17so707388igb.15 for ; Fri, 18 Apr 2014 07:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=icgUPaRgQGKguM4V/5VEiGNThP3w6kP6Lpu+DAg0asA=; b=NYjYQniCWjRMTLtXeMGjJWw8PBur0Ekv5XljeCTOxy0FCetk6JvFSD1xoG212hLi0t Ry7YtXG5b6hK+VF4UkaCHYmv/QlC9BrKOLMCOYmjn4uRMmIX4WL8paNU63A3dGwl/dtu XHuZqd7uedxciSJ/Kq5wRfhHFqulLJFzuNMec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=icgUPaRgQGKguM4V/5VEiGNThP3w6kP6Lpu+DAg0asA=; b=nJ777IiG9UAfjBmWChzvAe92Eh9J2rvNJ6mv6YPGnBIlsoe1TezdZRbExsNaxdRgxe k3zvzveSTXQlKOPHxSE3R0nOX9cPRLztt8mvYffw9zCADOVGtv+UzJr37XfWkE4I/buk 192n2tOm7Tml7ASy1XYLqcjxCqZvLxe3lJQX/aUGUbQzwwMDIZjZWQP+LGfKjtXDfpxV Iw53yxoXQbhbcsDBr5CO+L+4d9O4qzuz3F5SGhAYDJk4r3oNmpBiUPT8LZO0fFcedn5z S+uEnr4Im0ZO3S1hmLs3Ce4A/UB98JqEKsbUZfW55B8SpqCQRh9OSHgeKcw1nH8KYwFD MtYg== X-Gm-Message-State: ALoCoQnI2BSMOx87S9zje/q3DdM+ZtxC0fRKKeCW9sd09JbfWaCAK0KSR5uRr4tEr/umGIzpxHRP X-Received: by 10.42.247.132 with SMTP id mc4mr15246792icb.44.1397830222527; Fri, 18 Apr 2014 07:10:22 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id p18sm4434673igt.15.2014.04.18.07.10.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 07:10:22 -0700 (PDT) Message-ID: <5351324C.9070808@getjive.com> Date: Fri, 18 Apr 2014 08:10:20 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Simon Perreault , tram@ietf.org References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E816B.1020204@acm.org> <533EB302.10107@viagenie.ca> In-Reply-To: <533EB302.10107@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/SRdS2yxerFyMAEdJLDLTHAkmRnw Subject: Re: [tram] Open issue #4: domain/ip address handling in stun-dtls [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 14:10:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/4/14, 7:26 AM, Simon Perreault wrote: > Le 2014-04-04 05:54, Marc Petit-Huguenin a écrit : >> What we would suggest is to to add a new member in the >> RTCIceServer dictionary to carry the domain name (names?) to >> validate in case IP addresses are used in the STUN/TURN URI >> (pretty much like what was done for the username and password). > > So if the client always has access to the domain name, why wouldn't > it always resolve by itself? Well, the point is that when the server is providing an URI that contains an IP address (probably because it does not want the TURN client in the browser to spend time doing a DNS resolution), then the client does not have the domain name, and so cannot verify the certificate. Passing the domain name in the js code, and from here to the TURN client implementation through the RTCIceServer dictionary will permit to verify it (AFAIK the js code does not have access to the certificate, so the verification cannot be done in the application) Note that we will have the same issue with DANE, that will need to get the domain name to securely retrieve the TLSA RR and, unless we had a boolean, a DNS query will also be required here. What was decided at the meeting was to forbid IP addresses in URIs, but I want to be sure that this is still the consensus (as that will be a MUST NOT use IP address in the document). > I would be very tempted to write this simple pseudocode: > > char *hostname; if (is_a_domain_name(uri_host)) hostname = > uri_host; else hostname = rtciceserver_host; > resolve_and_connect(hostname); > > Simon > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUTJMAAoJEMUNRP98lsiX08oIAJJ/pJ1sHIEaSPqhPGJMBwgT 6N1uLj6op3h56M7h8VIWhr3LPb4erMILd3TBIn29abpQDHQtHdRDmVBYmItZwCKi 01d1AQmVhiKPuaOH+XGk4bguNwIiF6mdgLvpxjswR3THE6AiD5NsYBcZBeXSWUxn bqOTQisHCuROYXwjfn4T/xftpM4bHc14ImeSjLZSu13ZBiNwif5Q2//lMAKeEtzP QnOrFR9patF2qyVuq1yHldYEwxwmINF7DZhMyudyy6koWkXzIDb7+BGLtlS3yGG9 34SuSBVnXfgmnV5e5WjeNBbblLCrj1A5rvmvB0ElSoxwz4WOVX9cWfdPR9r1IKg= =Ynxe -----END PGP SIGNATURE----- From nobody Fri Apr 18 07:57:20 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD891A03C4 for ; Fri, 18 Apr 2014 07:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Orr_D8kRFnSW for ; Fri, 18 Apr 2014 07:57:14 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3729A1A01AF for ; Fri, 18 Apr 2014 07:57:14 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so1674270ier.41 for ; Fri, 18 Apr 2014 07:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=4K5hoRXpa0Oq4Ze6k2ErNy3JO4iri5vggIk/QPcLJBk=; b=Sxv9SYvJMlxY49gADqqlqWrF0D66HL+jrhBOKFm3jh6A4mSHwVWdpcN9cMzDYf80Go qQhd/jsIa4hVZ9zsT6Q62u2PrQAp480z3jWNabXTQSsSRJHIXNr+hU5nPn2NfimHjhl3 /goKWwMVoIqtTVF5WSl2WpeCjDQwVi/DtOJWs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=4K5hoRXpa0Oq4Ze6k2ErNy3JO4iri5vggIk/QPcLJBk=; b=W5/nm4G7qbmwpuzmt79Px7Yfb/jkLM8PIatXRyG7ydrU7Yl1+aoX7qBPxjhslUo5fi PQZ//5tSheFq+jkeOoodUjZXkKm2cB6OhNzAYDVpGdTEQeGwRu+r2U6jyk/mPaziSCGZ 9q590UZUmdqYBPQWoRq3igVSyy/mt9DPpNTpcc0yzoMCiP83GeySHJSGhiSkR+K7Xj+S bbmn6b5O+4nXQxT4LvBX/pVzRvBxEp5I85BKk2KYGNcCgW4GIQeD2BstTf2KtNG1UXgn edLV+zi2OKJ9iQ6Mvsla5OX5pZ2Fp7SRVhL+be8vf4czDNQ0zV+Xyr4ZOGeqgTbPCvDT RnmA== X-Gm-Message-State: ALoCoQlmZT6J+N/UT3vkyeMDz2Gafbe1AJwAPt3nEvVO6Lx794TgJnYJQRT+VbfAnrzM/C6ssBDv X-Received: by 10.43.156.18 with SMTP id lk18mr2770132icc.77.1397833030199; Fri, 18 Apr 2014 07:57:10 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id lp5sm4755921igb.1.2014.04.18.07.57.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 07:57:09 -0700 (PDT) Message-ID: <53513D43.4050009@getjive.com> Date: Fri, 18 Apr 2014 08:57:07 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/U2RuE9SwM9LxPs0xT5xhHcpcVQ0 Subject: [tram] Review of draft-ietf-tram-auth-problems-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 14:57:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A1. 1. Title "Problems with STUN Authentication for TURN I would suggest to change the title to "Problems with STUN long-term Authentication for TURN", as the STUN short-term authentication is not discussed in this draft. TURN only uses long-term authentication, so "Problems with TURN Authentication" is fine too. A2. Section 1. Introduction, first paragraph. I think that this paragraph puts too much emphasis on WebRTC. WebRTC is the reason people are finding issues with the authentication, but it is not the reason for the issues. A3. Section 2. Notational Conventions This is an informational draft, so RFC 2119 key words (and the reference) do not need to be defined. besides, none of them are used in the document. A4. Section 4. Title Replace with "Problems with usage of long-term STUN Authentication" A5. Section 4, fourth bullet. This is an man-in-the-middle attack, so the text should say so. A6. Section 4, 5th bullet Note that this applies only to the TCP and UDP transports, as SNI can be used to select the tenant/realm when TLS or DTLS is used. A7. Section 4, 6th bullet. "This exposes the user credential to the Javascript which could be malicious". It is only a problem if somehow the web server sends a user/password that can be used to access something else than the TURN server resources. It is not a problem created by the long-term authentication, but by bad code or misconfiguration on the server side. If you really insist on saying something about this, it should about how long-term authentication creates the possibility that a web server sends credentials that can be reused elsewhere. I think that the 3rd bullet as the same issue: Privacy leakage is not a consequence of using long-term authentication, but of using usernames that can be matched with a real person or that can be reused to access other resources. A7. Section 8. References I think that because this is an Informational document, all the references must be Informative. Nits ==== - - Section 1. 4th bullet "ICE connectivity checks using server-reflexive candidate" The exact terminology in RFC 5245 is "server reflexive". - - Section 4, second paragraph "...is deployed in DMZ..." Expand the initialism. - - Section 4, sixth bullet s/Javascript needs be know/JavaScript code needs to know/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUT1DAAoJEMUNRP98lsiX2j8IAI887pQ2p5EpzjjjHXHykUe1 mDfUX1wjs5YO7067sWV0s7gHev5G9h6NIo4fjQ8JNNmng3WkBn6hPT1k3HXz4KEd CpHFiihPMvjstjUv6AUtAF4igiRO2V4rkCbiHzxXt268+QTnW3Whzsjlq01pD6Pj RZcCBE/ASHy+8wUdV+CpF6ZHFU6+165pajiaEusMfrCLAqlin/Rj3aRBBe+s7/s7 yrHTlsQzEYPKdAvi6qD0MlZ6+/jtari0VJhQA5/fvHsa+3GA6/z9h5nACfXI+yh2 j9So3/qD90njHQFtxQXvspKasYagZjwO93RxLzIYKVy2BDMHlmsGL7wJ62Vo55o= =YfrU -----END PGP SIGNATURE----- From nobody Tue Apr 22 07:04:53 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208671A0406 for ; Tue, 22 Apr 2014 07:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 j9xV5CsBd8Et for ; Tue, 22 Apr 2014 07:04:47 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9D1A0400 for ; Tue, 22 Apr 2014 07:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3146; q=dns/txt; s=iport; t=1398175482; x=1399385082; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/BBL/8A09wEol2hp2w/+sVOIjhSKKpZNslH0/xzOJTE=; b=G3xVoIALygKBebqGTtPS9+IMN4xriQ0PKimg1XZL/DKqQ1PeV2JjAo+b ANugfttQvZZCn3sUTcKYWACY5Sy9iGR7kOtdLpYzy3nTpdcK8tdENVe1D ZCxMqtwg5ANe2ZlE7GRuJV8zYWaEPbGqecHKlEbyTz1DzYLNEDKy60YJ9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFALB1VlOtJV2Z/2dsb2JhbABPCoMGT1e8W4c7gRUWdIIlAQEBAwEBAQEmRRALAgECBhguIQYLJQIEE4gtAwkIDcVKDYZrEwSMPoE8KTqDJIEUBIksjVaBbo0AhVKBcoE/gis X-IronPort-AV: E=Sophos;i="4.97,904,1389744000"; d="scan'208";a="37749759" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 22 Apr 2014 14:04:41 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3ME4fLu004236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Apr 2014 14:04:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 09:04:41 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "tram@ietf.org" Thread-Topic: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: AQHPT+yZJikTBgKlDUC8PeejTqIjLQ== Importance: high X-Priority: 1 Date: Tue, 22 Apr 2014 14:04:41 +0000 Message-ID: <18C1CCED-887D-4A56-BEC2-3B2FE7B99482@cisco.com> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@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.116.132.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1538A8E0A4972A46AFB3EDCC8A4571B6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/WxGtaWn9XVnuLhiWSlNjacRPSSo Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 14:04:52 -0000 Apologize for the delay (day job and stuff...), but based on this discussio= n, we have just submitted a draft registering a STUN ALPN protocol identifi= er. Review comments welcome. There are two things we need WG direction on: (1) We have an open item that requires discussion: =20 In various offline discussions some have expressed a desire to add an additional ALPN protocol identifier for TURN (see IANA Considerations below for example registration). ALPN can be used more granularly to externally identify more of the protocol variants and their different properties (i.e., STUN and TURN over TLS/DTLS). The advantage in dividing it this way is that these different forms can be externally identified (obviously, there isn't any inherent value in the different identifiers from within the TLS handshake).There are two main disadvantages. the first is that this two application protocol approach may make implementations more complicated/confusing. The second is that there may be difficulty in differentiating the two with ALPN when TURN was specifically designed to be able to run on the same port as STUN usage (in section 13 of RFC 5389). Section 4.1.1.2 of RFC 5245 explicitly says that "If the Allocate request is rejected because the server lacks resources to fulfill it, the agent SHOULD instead send a Binding request to obtain a server reflexive candidate." Does that prove there is no need to differentiate TURN and STUN request on UDP/TCP or TLS and now DTLS? Are there sufficiently meaningful differences between the usages to warrant separate STUN and TURN ALPN identifiers? (2) How do we progress this draft? Create a new milestone and adopt as a TR= AM WG item or is best handled as an AD-sponsored individual draft? Thanks, Gonzalo On Apr 4, 2014, at 4:17 PM, Oleg Moskalenko wrote: > If ALPN is really independent of DTLS, I see no reason why they have to b= e combined in the draft document that was created solely for the DTLS featu= re introduction for STUNl. >=20 >=20 > On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) wrote: >=20 > On Apr 4, 2014, at 2:00 PM, Simon Perreault = wrote: >=20 > > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit : > >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't se= em it should be buried in STUNoDTLS. Shall we produce a dedicated draft fo= r this? > > > > My preference would be for "buried in STUNoDTLS". :) But I'm open to ar= guments for a dedicated draft. >=20 > My position is that the ALPN reg is entirely independent of STUNoDTLS, wh= ich is why we considered more contextually relevant for the broader STUNbis= effort. A standalone dedicated ALPN reg doc to point to seems cleaner to = me, but I'm open to WG decision on this. >=20 > -G >=20 > > > > Simon >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 From nobody Wed Apr 23 05:33:58 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB021A01C3 for ; Wed, 23 Apr 2014 05:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 8aUwloEWMk3q for ; Wed, 23 Apr 2014 05:33:55 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id ACB621A0357 for ; Wed, 23 Apr 2014 05:33:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5C2217C5370 for ; Wed, 23 Apr 2014 14:33:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh3YuC7HW0mz for ; Wed, 23 Apr 2014 14:33:48 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 393217C536E for ; Wed, 23 Apr 2014 14:33:48 +0200 (CEST) Message-ID: <5357B32B.3070700@alvestrand.no> Date: Wed, 23 Apr 2014 14:33:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vAwxWWjVxROa_M-QBvGUOaArjQ8 Subject: [tram] Question about scope of TRAM 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, 23 Apr 2014 12:33:57 -0000 On the RTCWEB list, the following claim was made: > Here, in TRAM we want to go beyond Level 4 QoS (already available and > working as good as it can on the Internet), to give quality demanding WebRTC > real-time traffic better QoE by: > a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using > auto-discovered TURN servers) > or > b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using > auto-discovered TURN servers). Here we must have traffic shaping mechanisms > working, and with correct and sufficient information to do the job. This is > why we in TRAM discuss DISCUSS/MALICE, > draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the > payload type (PT) idea/intent in RTP packets (by now conveying bandwidth and > traffic type in the RTP extension header > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html. > Before reacting to that, I want to check: Is it the opinion of the TRAM chairs that this is a fair description of a subject that is being actively discussed in the TRAM WG? Harald From nobody Wed Apr 23 06:09:52 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA2F1A039B for ; Wed, 23 Apr 2014 06:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 1BIs6vbkdiZD for ; Wed, 23 Apr 2014 06:09:45 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 93A481A0394 for ; Wed, 23 Apr 2014 06:09:45 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B7B57413C6 for ; Wed, 23 Apr 2014 09:09:39 -0400 (EDT) Message-ID: <5357BB93.1040206@viagenie.ca> Date: Wed, 23 Apr 2014 09:09:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <5357B32B.3070700@alvestrand.no> In-Reply-To: <5357B32B.3070700@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/55WZSGrrePNOwufp4pxGwfBo4AM Subject: Re: [tram] Question about scope of TRAM 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, 23 Apr 2014 13:09:47 -0000 Le 2014-04-23 08:33, Harald Alvestrand a écrit : > On the RTCWEB list, the following claim was made: > >> Here, in TRAM we want to go beyond Level 4 QoS (already available and >> working as good as it can on the Internet), to give quality demanding >> WebRTC >> real-time traffic better QoE by: >> a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using >> auto-discovered TURN servers) >> or >> b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using >> auto-discovered TURN servers). Here we must have traffic shaping >> mechanisms >> working, and with correct and sufficient information to do the job. >> This is >> why we in TRAM discuss DISCUSS/MALICE, >> draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the >> payload type (PT) idea/intent in RTP packets (by now conveying >> bandwidth and >> traffic type in the RTP extension header >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html. >> > > Before reacting to that, I want to check: > > Is it the opinion of the TRAM chairs that this is a fair description of > a subject that is being actively discussed in the TRAM WG? QoS is out of TRAM's scope. 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 nobody Wed Apr 23 07:57:55 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADE11A02D7 for ; Wed, 23 Apr 2014 07:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 R0VH90B3sOmS for ; Wed, 23 Apr 2014 07:57:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52A1A03C4 for ; Wed, 23 Apr 2014 07:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2768; q=dns/txt; s=iport; t=1398265061; x=1399474661; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Tu5Eaz+rCnpEzzoHlb4A1gQ0ErSPMsajU1TxcqeApiY=; b=IZh8+W/8j7Ot1TUuCXqKhIR8crAjb9SOkYTc9XWnxHyTqpieppn+2k8l SQpk9w6AIIkEQRxHjN5X7mgh7vjwKcA88i2TorhbV60M2+H6HOFPz+zXg nd5lUJvtpKI8a0T7iidNMzLi7fZdp/aIysacOGbHBpXxf8MmVUbB39MR8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooHANbTV1OtJV2c/2dsb2JhbABZgwZPUQaDD8EkGYEBFnSCJQEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAGIOAgFrCGjHReBKYx+OAaCaTWBFQSaLJEegzGBayQc X-IronPort-AV: E=Sophos;i="4.97,912,1389744000"; d="scan'208";a="319736200" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 23 Apr 2014 14:57:41 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3NEvfaq011301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Apr 2014 14:57:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 09:57:40 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt Thread-Index: AQHPXv28cXY9xwDEHEmcqoJxFv8N0psfPlEA Date: Wed, 23 Apr 2014 14:57:40 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431998F@xmb-rcd-x10.cisco.com> References: <20140423141008.9182.47236.idtracker@ietfa.amsl.com> In-Reply-To: <20140423141008.9182.47236.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/dixh8qvFLhTMYjHZG9BWDfCasPw Subject: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 14:57:52 -0000 UmV2aXNlZCBkcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHogaGFzIGJlZW4g cHVibGlzaGVkLiBNYWpvciBjaGFuZ2UgaXMgdGhhdCBpdOKAmXMgbm93IHVzaW5nIHNlbGYtY29u dGFpbmVkIHRva2VuIGFuZCBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gdGhl IFdHLiANCkZ1cnRoZXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpU aGFua3MgYW5kIFJlZ2FyZHMsDQotQXV0aG9ycw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjMsIDIwMTQgNzo0MCBQTQ0KVG86 IFJhbSBNb2hhbiBSIChybW9oYW5yKTsgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IFRpcnVt YWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBKdXN0 aW4gVWJlcnRpOyBKdXN0aW4gVWJlcnRpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBS YW0gTW9oYW4gUiAocm1vaGFucikNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAxLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0 aHotMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dh ciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHoNClJldmlzaW9uOgkwMQ0KVGl0bGU6 CQlUVVJOIEV4dGVuc2lvbiBmb3IgVGhpcmQgUGFydHkgQXV0aG9yaXphdGlvbg0KRG9jdW1lbnQg ZGF0ZToJMjAxNC0wNC0yMw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJ MTQNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDEudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHktdHJhbS10 dXJuLXRoaXJkLXBhcnR5LWF1dGh6Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMQ0KRGlm ZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXJlZGR5 LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgcHJvcG9zZXMgdGhlIHVzZSBvZiBPQXV0aCB0byBvYnRhaW4gYW5kIHZhbGlkYXRlDQog ICBlcGhlbWVyYWwgdG9rZW5zIHRoYXQgY2FuIGJlIHVzZWQgZm9yIFRVUk4gYXV0aGVudGljYXRp b24uICBUaGUgdXNhZ2UNCiAgIG9mIGVwaGVtZXJhbCB0b2tlbnMgZW5zdXJlIHRoYXQgYWNjZXNz IHRvIGEgVFVSTiBzZXJ2ZXIgY2FuIGJlDQogICBjb250cm9sbGVkIGV2ZW4gaWYgdGhlIHRva2Vu cyBhcmUgY29tcHJvbWlzZWQsIGFzIGlzIHRoZSBjYXNlIGluDQogICBXZWJSVEMgd2hlcmUgVFVS TiBjcmVkZW50aWFscyBtdXN0IGJlIHNwZWNpZmllZCBpbiBKYXZhc2NyaXB0Lg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Apr 23 08:56:56 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784A21A0016 for ; Wed, 23 Apr 2014 08:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 hl6j1Xuy2AlT for ; Wed, 23 Apr 2014 08:56:51 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 0586E1A0341 for ; Wed, 23 Apr 2014 08:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3591; q=dns/txt; s=iport; t=1398268605; x=1399478205; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=miznmaBXO9JyfvQ1+NJEKnzjC2Bawl70bWIj9UWLNno=; b=DV/6O3oPT7TuH72gF9as6a9tPn7btRAHiJaunC6yK6tH1FqlUfF+ZOvK d+xHLuhIbUZniJOdvmH5HEN6VJLpwZrqoY8+vbxFVsENexJjDMUej3ZUG qQHNyUyxSg7RF+traWNM8dZO0R/KjPdcNEzPi6266N6M2jQ9ITVBs+BIL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAGriV1OtJA2H/2dsb2JhbABQCYMGT1e8eoc6gRoWdIIlAQEBAwEBAQFrGwIBCBgYCwsnCyUCBBOIOQgNzncXjX0HIToYgwyBFQSJLY9IklWBcoE/gWskHA X-IronPort-AV: E=Sophos;i="4.97,912,1389744000"; d="scan'208";a="38116223" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP; 23 Apr 2014 15:56:45 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3NFujKQ020245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Apr 2014 15:56:45 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 10:56:44 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "tram@ietf.org" Thread-Topic: [tram] Open issue #4: domain/ip address handling in stun-dtls [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: AQHPWw/3XR9B/GQhtUCrITXRslVoppsftvEA Date: Wed, 23 Apr 2014 15:56:44 +0000 Message-ID: <9A7033B3-5D0E-4F70-998B-0E50529AE2B7@cisco.com> References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E816B.1020204@acm.org> <533EB302.10107@viagenie.ca> <5351324C.9070808@getjive.com> In-Reply-To: <5351324C.9070808@getjive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.179] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <121C8E6FDD6A184898A5A8E74BD54B23@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/VV7C_wkF8UcIy9iDWkhdSkN2gEc Subject: Re: [tram] Open issue #4: domain/ip address handling in stun-dtls [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:56:53 -0000 Folks -=20 We are planning to close on this open issue in the draft. Appreciate any f= inal comments as we are planning to publish the next version in the next fe= w days. More inline... On Apr 18, 2014, at 10:10 AM, Marc Petit-Huguenin wrot= e: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > On 4/4/14, 7:26 AM, Simon Perreault wrote: >> Le 2014-04-04 05:54, Marc Petit-Huguenin a =E9crit : >>> What we would suggest is to to add a new member in the >>> RTCIceServer dictionary to carry the domain name (names?) to >>> validate in case IP addresses are used in the STUN/TURN URI >>> (pretty much like what was done for the username and password). >>=20 >> So if the client always has access to the domain name, why wouldn't >> it always resolve by itself? >=20 > Well, the point is that when the server is providing an URI that > contains an IP address (probably because it does not want the TURN > client in the browser to spend time doing a DNS resolution), then the > client does not have the domain name, and so cannot verify the > certificate. Passing the domain name in the js code, and from here to > the TURN client implementation through the RTCIceServer dictionary > will permit to verify it (AFAIK the js code does not have access to > the certificate, so the verification cannot be done in the application) >=20 > Note that we will have the same issue with DANE, that will need to get > the domain name to securely retrieve the TLSA RR and, unless we had a > boolean, a DNS query will also be required here. >=20 > What was decided at the meeting was to forbid IP addresses in URIs, > but I want to be sure that this is still the consensus (as that will > be a MUST NOT use IP address in the document). In London the WG decided we should forbid ip addresses. The following text = is proposed to address this (note that equivalent text is proposed for TURN= URI as well): "The value MUST be used when using the rules in Section 7.2.2 of [RFC5389] to verify the server identity. A STUN URI containing an IP address MUST be rejected, unless the domain is provided by the same mechanism that provided the STUN URI, and that this domain name can be passed to the verification code." Note that a bit of wiggle room is provided if there is an alternate way to = pass the domain name to the (D)TLS verifier (CA or DANE). This was added in= case of modification of the WebRTC API, but still ensuring that the domain= name can be verified in all cases. Sound OK? Thanks, Gonzalo >=20 >> I would be very tempted to write this simple pseudocode: >>=20 >> char *hostname; if (is_a_domain_name(uri_host)) hostname =3D >> uri_host; else hostname =3D rtciceserver_host;=20 >> resolve_and_connect(hostname); >>=20 >> Simon >>=20 >>=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQEcBAEBAgAGBQJTUTJMAAoJEMUNRP98lsiX08oIAJJ/pJ1sHIEaSPqhPGJMBwgT > 6N1uLj6op3h56M7h8VIWhr3LPb4erMILd3TBIn29abpQDHQtHdRDmVBYmItZwCKi > 01d1AQmVhiKPuaOH+XGk4bguNwIiF6mdgLvpxjswR3THE6AiD5NsYBcZBeXSWUxn > bqOTQisHCuROYXwjfn4T/xftpM4bHc14ImeSjLZSu13ZBiNwif5Q2//lMAKeEtzP > QnOrFR9patF2qyVuq1yHldYEwxwmINF7DZhMyudyy6koWkXzIDb7+BGLtlS3yGG9 > 34SuSBVnXfgmnV5e5WjeNBbblLCrj1A5rvmvB0ElSoxwz4WOVX9cWfdPR9r1IKg=3D > =3DYnxe > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Apr 23 09:11:02 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5871A03CC for ; Wed, 23 Apr 2014 09:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 spDcqiLHSzaQ for ; Wed, 23 Apr 2014 09:10:52 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1E951A0382 for ; Wed, 23 Apr 2014 09:10:40 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0DCEF403CA for ; Wed, 23 Apr 2014 12:10:35 -0400 (EDT) Message-ID: <5357E5FA.5080504@viagenie.ca> Date: Wed, 23 Apr 2014 12:10:34 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E816B.1020204@acm.org> <533EB302.10107@viagenie.ca> <5351324C.9070808@getjive.com> <9A7033B3-5D0E-4F70-998B-0E50529AE2B7@cisco.com> In-Reply-To: <9A7033B3-5D0E-4F70-998B-0E50529AE2B7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/8wFzNC9wAHTZzQm-HcEnUnW6QlU Subject: Re: [tram] Open issue #4: domain/ip address handling in stun-dtls [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:10:57 -0000 Le 2014-04-23 11:56, Gonzalo Salgueiro (gsalguei) a écrit : > In London the WG decided we should forbid ip addresses. The following text is proposed to address this (note that equivalent text is proposed for TURN URI as well): > > "The value MUST be used when using the rules in Section 7.2.2 > of [RFC5389] to verify the server identity. A STUN URI containing an IP > address MUST be rejected, unless the domain is provided by the same > mechanism that provided the STUN URI, and that this domain name can be > passed to the verification code." > > Note that a bit of wiggle room is provided if there is an alternate way to pass the domain name to the (D)TLS verifier (CA or DANE). This was added in case of modification of the WebRTC API, but still ensuring that the domain name can be verified in all cases. > > Sound OK? Works for me! 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 nobody Wed Apr 23 12:09:38 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829931A049A for ; Wed, 23 Apr 2014 12:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQciz9jy0EYF for ; Wed, 23 Apr 2014 12:09:34 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id BD7841A04AC for ; Wed, 23 Apr 2014 12:09:31 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404232109229069; Wed, 23 Apr 2014 21:09:22 +0200 From: "Karl Stahl" To: "'Simon Perreault'" , References: <5357B32B.3070700@alvestrand.no> <5357BB93.1040206@viagenie.ca> In-Reply-To: <5357BB93.1040206@viagenie.ca> Date: Wed, 23 Apr 2014 21:09:26 +0200 Message-ID: <010c01cf5f27$8bc6f970$a354ec50$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9e9U2pkNm0w9zqQ+e6N4LKN+vRnwAMarDA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/8WA0kmr7tvymTE8mOKHA1njQphk Subject: Re: [tram] Question about scope of TRAM 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, 23 Apr 2014 19:09:36 -0000 Please disregard my TRAM-references. I missed to delete them when = copying this technical text from early March into the rtcweb discussion now. = Sorry. /Karl=20 -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault Skickat: den 23 april 2014 15:10 Till: tram@ietf.org =C4mne: Re: [tram] Question about scope of TRAM Le 2014-04-23 08:33, Harald Alvestrand a =E9crit : > On the RTCWEB list, the following claim was made: >=20 >> Here, in TRAM we want to go beyond Level 4 QoS (already available and = >> working as good as it can on the Internet), to give quality demanding = >> WebRTC real-time traffic better QoE by: >> a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using=20 >> auto-discovered TURN servers) or b. Forcing real-time traffic into=20 >> IP-pipes having Level 3 QoS (using auto-discovered TURN servers).=20 >> Here we must have traffic shaping mechanisms working, and with=20 >> correct and sufficient information to do the job. >> This is >> why we in TRAM discuss DISCUSS/MALICE,=20 >> draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating=20 >> the payload type (PT) idea/intent in RTP packets (by now conveying=20 >> bandwidth and traffic type in the RTP extension header=20 >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html. >> >=20 > Before reacting to that, I want to check: >=20 > Is it the opinion of the TRAM chairs that this is a fair description=20 > of a subject that is being actively discussed in the TRAM WG? QoS is out of TRAM's scope. 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 nobody Thu Apr 24 07:59:00 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882831A02BF for ; Thu, 24 Apr 2014 07:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 FghhiTEhxN3j for ; Thu, 24 Apr 2014 07:58:57 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id C421E1A01DC for ; Thu, 24 Apr 2014 07:58:56 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A550547509 for ; Thu, 24 Apr 2014 14:58:50 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 98D39474D5 for ; Thu, 24 Apr 2014 14:58:50 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 8DF96FE054 for ; Thu, 24 Apr 2014 14:58:50 +0000 (GMT) Message-ID: <535926AA.2040606@akamai.com> Date: Thu, 24 Apr 2014 10:58:50 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140423141008.9182.47236.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2431998F@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2431998F@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/10pxjR6YG-oEbnq6qNtExgw34r0 Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 14:58:58 -0000 The current revision requires a unique key identifier (kid) per TURN server that will be shared between the authorization aerver and the TURN server. This has some drawbacks for 3rd party TURN service providers and their customers that I have some concerns about, the primary one being that the authorization server must maintain a key pair for each individual TURN server deployed by the TURN service provider. This adds complexity to the problem of deploying new TURN server capacity and compounds the problem of key rotation by increasing the number of keys. Additionally, it increases allocation establishment time by requiring the client to learn the correct kid from the TURN server in order to send the kid to the auth server in its token request. The client cannot optimize allocation because it is required to have access to the kid before contacting that auth server for a token. An alternative is for the auth server and the TURN service to share a single key pair, with any individual TURN server being able to decrypt and authenticate the token. This allows the TURN service provider to provision new relay capacity without any direct interaction with the auth server, and it also means that there is only one pre-shared keypair to be managed between the auth server and the TURN service. One shortcoming of this approach is that a single token could be considered valid by multiple TURN servers, and thus used by a compromised client to establish multiple allocations when only a single one was authorized. This risk is easily mitigated by requiring the client to send the relay server's IP address within the token request to the auth server (in place of the kid) and for the mac field within the encrypted token to include the server's IP address as part of the authenticated data. This would make the token's mac valid for just the intended receiver without increasing the size of the token. Another shortcoming of this approach is that compromise of one keypair is a global compromise, rather than just compromise of a single TURN relay. This risk is easily mitigated through relay-side monitoring/rate-limiting and the ability to manually rotate keys. Are there other shortcomings of this proposed change that I'm not thinking of? And do the mitigations that I describe seem reasonable? Thanks, --Brandon On 04/23/2014 10:57 AM, Tirumaleswar Reddy (tireddy) wrote: > Revised draft-reddy-tram-turn-third-party-authz has been published. Major change is that it’s now using self-contained token and addresses the comments received from the WG. > Further comments and suggestions are welcome. > > Thanks and Regards, > -Authors > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, April 23, 2014 7:40 PM > To: Ram Mohan R (rmohanr); Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); Justin Uberti; Justin Uberti; Tirumaleswar Reddy (tireddy); Ram Mohan R (rmohanr) > Subject: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt > > > A new version of I-D, draft-reddy-tram-turn-third-party-authz-01.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. > > Name: draft-reddy-tram-turn-third-party-authz > Revision: 01 > Title: TURN Extension for Third Party Authorization > Document date: 2014-04-23 > Group: Individual Submission > Pages: 14 > URL: http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-third-party-authz-01.txt > Status: https://datatracker.ietf.org/doc/draft-reddy-tram-turn-third-party-authz/ > Htmlized: http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-reddy-tram-turn-third-party-authz-01 > > Abstract: > This document proposes the use of OAuth to obtain and validate > ephemeral tokens that can be used for TURN authentication. The usage > of ephemeral tokens ensure that access to a TURN server can be > controlled even if the tokens are compromised, as is the case in > WebRTC where TURN credentials must be specified in Javascript. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Apr 24 08:04:25 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D241A032D for ; Thu, 24 Apr 2014 08:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 D1PjhQhFfdEv for ; Thu, 24 Apr 2014 08:04:21 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id DF4A71A0318 for ; Thu, 24 Apr 2014 08:04:20 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BBFC147470 for ; Thu, 24 Apr 2014 15:04:14 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id ABEA347425 for ; Thu, 24 Apr 2014 15:04:14 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id A002DFE055 for ; Thu, 24 Apr 2014 15:04:14 +0000 (GMT) Message-ID: <535927EE.4020709@akamai.com> Date: Thu, 24 Apr 2014 11:04:14 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140423141008.9182.47236.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2431998F@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2431998F@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7_kKKdy5p8pJ0mJGEJ-Ttfz7t_8 Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:04:23 -0000 One other comment that I have about the proposal is that I think the mac for the token should cover the encrypted token, rather than the encryption covering the mac. So, this ... struct { ushort key_length; opaque mac_key[key_length]; opaque timestamp[8]; long lifetime; opaque mac[16]; } token; would become this ... struct { opaque { ushort key_length; opaque mac_key[key_length]; opaque timestamp[8]; long lifetime; } encrypted_block; opaque mac[16]; } token; This may increase the size of the resulting token, but only by a small amount (at most 16 bytes). --Brandon On 04/23/2014 10:57 AM, Tirumaleswar Reddy (tireddy) wrote: > Revised draft-reddy-tram-turn-third-party-authz has been published. Major change is that it’s now using self-contained token and addresses the comments received from the WG. > Further comments and suggestions are welcome. > > Thanks and Regards, > -Authors > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, April 23, 2014 7:40 PM > To: Ram Mohan R (rmohanr); Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); Justin Uberti; Justin Uberti; Tirumaleswar Reddy (tireddy); Ram Mohan R (rmohanr) > Subject: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt > > > A new version of I-D, draft-reddy-tram-turn-third-party-authz-01.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. > > Name: draft-reddy-tram-turn-third-party-authz > Revision: 01 > Title: TURN Extension for Third Party Authorization > Document date: 2014-04-23 > Group: Individual Submission > Pages: 14 > URL: http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-third-party-authz-01.txt > Status: https://datatracker.ietf.org/doc/draft-reddy-tram-turn-third-party-authz/ > Htmlized: http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-reddy-tram-turn-third-party-authz-01 > > Abstract: > This document proposes the use of OAuth to obtain and validate > ephemeral tokens that can be used for TURN authentication. The usage > of ephemeral tokens ensure that access to a TURN server can be > controlled even if the tokens are compromised, as is the case in > WebRTC where TURN credentials must be specified in Javascript. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Apr 25 07:14:14 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADCF1A04E7 for ; Fri, 25 Apr 2014 07:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 Uw6fwVH1-GtS for ; Fri, 25 Apr 2014 07:14:10 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 87E851A048C for ; Fri, 25 Apr 2014 07:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8162; q=dns/txt; s=iport; t=1398435244; x=1399644844; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=OVJVcnWyyzphcCg/hIbe3ltTL2iL9gwbSKIf/rjVPdY=; b=F/+00gPKMsa6VX769dQmSgG6Vmsl5iqMy2WdThnsCZMnQJIg7iIaY+Wz +UjhnripC6hmJ5Vcdbo6zD/rs0lwDX6hS3hq8722GhH44mnR1srsKiabE PH+O9Rm+eVCFgmMhEXOUQW+HHLLu0vZnvtamJy+mYgAxk+zXWlhzWCq+c Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncHAExsWlOtJA2E/2dsb2JhbABZgwZPUQaCZboChzgZdhZ0giUBAQEDAQEBASAROgkHBwYBCBEEAQEBAgIGHQMCBCULFAEHAQkBBAESCAGIMAgIBacYo0cXgSmMTTILCyiCaTWBFQSVE4UqkSSBcoE/gWskHA X-IronPort-AV: E=Sophos;i="4.97,927,1389744000"; d="scan'208";a="38704409" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 25 Apr 2014 14:14:03 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s3PEE33B003266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 14:14:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 09:14:03 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt Thread-Index: Ac9gkJhkWMtc8Ab9QESd9WUP4nyc/w== Date: Fri, 25 Apr 2014 14:14:02 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431B044@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.52.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/mjI_Zz1DMhyL0kD7iuS3QJcw59g Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:14:12 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJhbmRvbiBXaWxsaWFtcw0KPiBTZW50OiBU aHVyc2RheSwgQXByaWwgMjQsIDIwMTQgODoyOSBQTQ0KPiBUbzogdHJhbUBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXJlZGR5LXRyYW0tdHVybi0NCj4gdGhpcmQtcGFydHktYXV0aHotMDEudHh0DQo+IA0KPiBUaGUg Y3VycmVudCByZXZpc2lvbiByZXF1aXJlcyBhIHVuaXF1ZSBrZXkgaWRlbnRpZmllciAoa2lkKSBw ZXIgVFVSTiBzZXJ2ZXIgdGhhdA0KPiB3aWxsIGJlIHNoYXJlZCBiZXR3ZWVuIHRoZSBhdXRob3Jp emF0aW9uIGFlcnZlciBhbmQgdGhlIFRVUk4gc2VydmVyLiBUaGlzIGhhcw0KPiBzb21lIGRyYXdi YWNrcyBmb3IgM3JkIHBhcnR5IFRVUk4gc2VydmljZSBwcm92aWRlcnMgYW5kIHRoZWlyIGN1c3Rv bWVycyB0aGF0IEkNCj4gaGF2ZSBzb21lIGNvbmNlcm5zIGFib3V0LCB0aGUgcHJpbWFyeSBvbmUg YmVpbmcgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXINCj4gbXVzdCBtYWludGFpbiBhIGtl eSBwYWlyIGZvciBlYWNoIGluZGl2aWR1YWwgVFVSTiBzZXJ2ZXIgZGVwbG95ZWQgYnkgdGhlIFRV Uk4NCj4gc2VydmljZSBwcm92aWRlci4gVGhpcyBhZGRzIGNvbXBsZXhpdHkgdG8gdGhlIHByb2Js ZW0gb2YgZGVwbG95aW5nIG5ldyBUVVJODQo+IHNlcnZlciBjYXBhY2l0eSBhbmQgY29tcG91bmRz IHRoZSBwcm9ibGVtIG9mIGtleSByb3RhdGlvbiBieSBpbmNyZWFzaW5nIHRoZQ0KPiBudW1iZXIg b2Yga2V5cy4NCj4gQWRkaXRpb25hbGx5LCBpdCBpbmNyZWFzZXMgYWxsb2NhdGlvbiBlc3RhYmxp c2htZW50IHRpbWUgYnkgcmVxdWlyaW5nIHRoZSBjbGllbnQgdG8NCj4gbGVhcm4gdGhlIGNvcnJl Y3Qga2lkIGZyb20gdGhlIFRVUk4gc2VydmVyIGluIG9yZGVyIHRvIHNlbmQgdGhlIGtpZCB0byB0 aGUgYXV0aA0KPiBzZXJ2ZXIgaW4gaXRzIHRva2VuIHJlcXVlc3QuIFRoZSBjbGllbnQgY2Fubm90 IG9wdGltaXplIGFsbG9jYXRpb24gYmVjYXVzZSBpdCBpcw0KPiByZXF1aXJlZCB0byBoYXZlIGFj Y2VzcyB0byB0aGUga2lkIGJlZm9yZSBjb250YWN0aW5nIHRoYXQgYXV0aCBzZXJ2ZXIgZm9yIGEN Cj4gdG9rZW4uDQoNCk5vLCB0aGUgY2xpZW50IG5lZWQgbm90IGhhdmUgdG8gbGVhcm4gdGhlIGtp ZCBmcm9tIHRoZSBUVVJOIHNlcnZlciBub3IgbmVlZHMgdG8gc2VuZCBpdCB0byB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIuIFNpbmNlIHRoZSBraWQgaXMgdW5pcXVlIHBlciBUVVJOIHNlcnZlciwg dGhlIGNsaWVudCBuZWVkcyB0byBvbmx5IGNvbnZleSB0aGUgVFVSTiBzZXJ2ZXIgSVAgYWRkcmVz cyB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2hlbiByZXF1ZXN0aW5nIHRoZSB0b2tlbi4g VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlkZW50aWZpZXMgdGhlIGtleWluZyBtYXRlcmlhbCB1 c2luZyB0aGUgVFVSTiBzZXJ2ZXIgSVAgYWRkcmVzcyBhbmQgcmV0dXJucyB0aGUgc2VsZi1jb250 YWluZWQgdG9rZW4sIG1hY19rZXksIGtpZCwgZXhwaXJlc19pbiBldGMuICBDbGllbnQgaGFzIHRv IHBhc3MgdGhlIGtpZCBhbmQgc2VsZi1jb250YWluZWQgdG9rZW4gdG8gdGhlIFRVUk4gc2VydmVy IGZvciBhdXRob3JpemF0aW9uLiBJIGRvbid0IHNlZSBhbnkgaW5jcmVhc2UgaW4gdGhlIGFsbG9j YXRpb24gZXN0YWJsaXNobWVudCB0aW1lIGJlY2F1c2Ugb2YgdXNpbmcga2lkLg0KDQotVGlydQ0K DQo+IA0KPiBBbiBhbHRlcm5hdGl2ZSBpcyBmb3IgdGhlIGF1dGggc2VydmVyIGFuZCB0aGUgVFVS TiBzZXJ2aWNlIHRvIHNoYXJlIGEgc2luZ2xlIGtleQ0KPiBwYWlyLCB3aXRoIGFueSBpbmRpdmlk dWFsIFRVUk4gc2VydmVyIGJlaW5nIGFibGUgdG8gZGVjcnlwdCBhbmQgYXV0aGVudGljYXRlIHRo ZQ0KPiB0b2tlbi4gVGhpcyBhbGxvd3MgdGhlIFRVUk4gc2VydmljZSBwcm92aWRlciB0byBwcm92 aXNpb24gbmV3IHJlbGF5IGNhcGFjaXR5DQo+IHdpdGhvdXQgYW55IGRpcmVjdCBpbnRlcmFjdGlv biB3aXRoIHRoZSBhdXRoIHNlcnZlciwgYW5kIGl0IGFsc28gbWVhbnMgdGhhdCB0aGVyZQ0KPiBp cyBvbmx5IG9uZSBwcmUtc2hhcmVkIGtleXBhaXIgdG8gYmUgbWFuYWdlZCBiZXR3ZWVuIHRoZSBh dXRoIHNlcnZlciBhbmQgdGhlDQo+IFRVUk4gc2VydmljZS4NCj4gDQo+IE9uZSBzaG9ydGNvbWlu ZyBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgYSBzaW5nbGUgdG9rZW4gY291bGQgYmUgY29uc2lk ZXJlZA0KPiB2YWxpZCBieSBtdWx0aXBsZSBUVVJOIHNlcnZlcnMsIGFuZCB0aHVzIHVzZWQgYnkg YSBjb21wcm9taXNlZCBjbGllbnQgdG8NCj4gZXN0YWJsaXNoIG11bHRpcGxlIGFsbG9jYXRpb25z IHdoZW4gb25seSBhIHNpbmdsZSBvbmUgd2FzIGF1dGhvcml6ZWQuIFRoaXMgcmlzayBpcw0KPiBl YXNpbHkgbWl0aWdhdGVkIGJ5IHJlcXVpcmluZyB0aGUgY2xpZW50IHRvIHNlbmQgdGhlIHJlbGF5 IHNlcnZlcidzIElQIGFkZHJlc3Mgd2l0aGluDQo+IHRoZSB0b2tlbiByZXF1ZXN0IHRvIHRoZSBh dXRoIHNlcnZlciAoaW4gcGxhY2Ugb2YgdGhlIGtpZCkgYW5kIGZvciB0aGUgbWFjIGZpZWxkDQo+ IHdpdGhpbiB0aGUgZW5jcnlwdGVkIHRva2VuIHRvIGluY2x1ZGUgdGhlIHNlcnZlcidzIElQIGFk ZHJlc3MgYXMgcGFydCBvZiB0aGUNCj4gYXV0aGVudGljYXRlZCBkYXRhLiBUaGlzIHdvdWxkIG1h a2UgdGhlIHRva2VuJ3MgbWFjIHZhbGlkIGZvciBqdXN0IHRoZSBpbnRlbmRlZA0KPiByZWNlaXZl ciB3aXRob3V0IGluY3JlYXNpbmcgdGhlIHNpemUgb2YgdGhlIHRva2VuLg0KPiANCj4gQW5vdGhl ciBzaG9ydGNvbWluZyBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgY29tcHJvbWlzZSBvZiBvbmUg a2V5cGFpciBpcyBhDQo+IGdsb2JhbCBjb21wcm9taXNlLCByYXRoZXIgdGhhbiBqdXN0IGNvbXBy b21pc2Ugb2YgYSBzaW5nbGUgVFVSTiByZWxheS4gVGhpcyByaXNrDQo+IGlzIGVhc2lseSBtaXRp Z2F0ZWQgdGhyb3VnaCByZWxheS1zaWRlIG1vbml0b3JpbmcvcmF0ZS1saW1pdGluZyBhbmQgdGhl IGFiaWxpdHkgdG8NCj4gbWFudWFsbHkgcm90YXRlIGtleXMuDQo+IA0KPiBBcmUgdGhlcmUgb3Ro ZXIgc2hvcnRjb21pbmdzIG9mIHRoaXMgcHJvcG9zZWQgY2hhbmdlIHRoYXQgSSdtIG5vdCB0aGlu a2luZyBvZj8NCj4gQW5kIGRvIHRoZSBtaXRpZ2F0aW9ucyB0aGF0IEkgZGVzY3JpYmUgc2VlbSBy ZWFzb25hYmxlPw0KPiANCj4gVGhhbmtzLA0KPiAtLUJyYW5kb24NCj4gDQo+IE9uIDA0LzIzLzIw MTQgMTA6NTcgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgd3JvdGU6DQo+ID4gUmV2 aXNlZCBkcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHogaGFzIGJlZW4gcHVi bGlzaGVkLiBNYWpvcg0KPiBjaGFuZ2UgaXMgdGhhdCBpdOKAmXMgbm93IHVzaW5nIHNlbGYtY29u dGFpbmVkIHRva2VuIGFuZCBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzDQo+IHJlY2VpdmVkIGZyb20g dGhlIFdHLg0KPiA+IEZ1cnRoZXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21l Lg0KPiA+DQo+ID4gVGhhbmtzIGFuZCBSZWdhcmRzLA0KPiA+IC1BdXRob3JzDQo+ID4NCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPiBTZW50OiBXZWRuZXNk YXksIEFwcmlsIDIzLCAyMDE0IDc6NDAgUE0NCj4gPiBUbzogUmFtIE1vaGFuIFIgKHJtb2hhbnIp OyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVzd2FyDQo+ID4gUmVkZHkgKHRp cmVkZHkpOyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgSnVzdGluIFViZXJ0aTsgSnVzdGlu DQo+ID4gVWJlcnRpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBSYW0gTW9oYW4gUiAo cm1vaGFucikNCj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4g ZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAxLnR4dA0KPiA+DQo+ID4N Cj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJkLXBh cnR5LWF1dGh6LTAxLnR4dA0KPiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg VGlydW1hbGVzd2FyIFJlZGR5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9yeS4N Cj4gPg0KPiA+IE5hbWU6CQlkcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHoN Cj4gPiBSZXZpc2lvbjoJMDENCj4gPiBUaXRsZToJCVRVUk4gRXh0ZW5zaW9uIGZvciBUaGlyZCBQ YXJ0eSBBdXRob3JpemF0aW9uDQo+ID4gRG9jdW1lbnQgZGF0ZToJMjAxNC0wNC0yMw0KPiA+IEdy b3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gUGFnZXM6CQkxNA0KPiA+IFVSTDogICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS10 cmFtLXR1cm4tdGhpcmQtDQo+IHBhcnR5LWF1dGh6LTAxLnR4dA0KPiA+IFN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yZWRkeS10cmFtLXR1cm4t dGhpcmQtDQo+IHBhcnR5LWF1dGh6Lw0KPiA+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktDQo+IGF1dGh6 LTAxDQo+ID4gRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LXJlZGR5LXRyYW0tdHVybi10aGlyZC1wYXJ0eS0NCj4gYXV0aHotMDENCj4gPg0KPiA+ IEFic3RyYWN0Og0KPiA+ICAgICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgT0F1 dGggdG8gb2J0YWluIGFuZCB2YWxpZGF0ZQ0KPiA+ICAgICBlcGhlbWVyYWwgdG9rZW5zIHRoYXQg Y2FuIGJlIHVzZWQgZm9yIFRVUk4gYXV0aGVudGljYXRpb24uICBUaGUgdXNhZ2UNCj4gPiAgICAg b2YgZXBoZW1lcmFsIHRva2VucyBlbnN1cmUgdGhhdCBhY2Nlc3MgdG8gYSBUVVJOIHNlcnZlciBj YW4gYmUNCj4gPiAgICAgY29udHJvbGxlZCBldmVuIGlmIHRoZSB0b2tlbnMgYXJlIGNvbXByb21p c2VkLCBhcyBpcyB0aGUgY2FzZSBpbg0KPiA+ICAgICBXZWJSVEMgd2hlcmUgVFVSTiBjcmVkZW50 aWFscyBtdXN0IGJlIHNwZWNpZmllZCBpbiBKYXZhc2NyaXB0Lg0KPiA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+DQo+ID4gVGhlIElF VEYgU2VjcmV0YXJpYXQNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gPiB0cmFtQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo+ID4NCj4g DQo+IC0tDQo+IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5n aW5lZXIgRW1lcmdpbmcgUHJvZHVjdHMNCj4gRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dp ZXMgSW5jLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== From nobody Fri Apr 25 07:58:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074511A04AF for ; Fri, 25 Apr 2014 07:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 868iWh1XTA5G for ; Fri, 25 Apr 2014 07:58:11 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 58F091A01DA for ; Fri, 25 Apr 2014 07:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5318; q=dns/txt; s=iport; t=1398437885; x=1399647485; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yj2nZ3zr5XN4P/giwlytdM3kUo/haO6uzG0aO+IczQ0=; b=bs/RW/AFjPylZv4d3WmqEXXQ4g3PVQZwaDasn+Tnz2T1V/1+vSZvTn9F B3MgHJdXw5USrTZu8DFnmJ3DQ8AbhulRxK8uLKrJNpbi/QrNRCpkD445W P2MSR2vVjwjr6IeamdY9i9LD4lnc6jChDTYmyGaP+MbcRX7alBfwWnJtl M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncHAFJ3WlOtJV2Z/2dsb2JhbABZgwZPUQaCZboDhzgZeBZ0giUBAQEEAQEBIBE6CQ4GAQgRBAEBAQICBh0DAgQlCxQBBwEJAQQBEggBiDgIBaZ6o0kXgSmMfxYogmk1gRUEmj2RJIFygT+BayQc X-IronPort-AV: E=Sophos;i="4.97,927,1389744000"; d="scan'208";a="38721318" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 25 Apr 2014 14:58:02 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3PEw211008032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 14:58:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 09:58:02 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt Thread-Index: Ac9glr7tV/qo61XWQTuyIrN/c2apvg== Date: Fri, 25 Apr 2014 14:58:02 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431B0CD@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.52.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/u_arFzqAGTQD6V4cA99AumQSMq8 Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:58:14 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJhbmRvbiBXaWxsaWFtcw0KPiBTZW50OiBU aHVyc2RheSwgQXByaWwgMjQsIDIwMTQgODozNCBQTQ0KPiBUbzogdHJhbUBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXJlZGR5LXRyYW0tdHVybi0NCj4gdGhpcmQtcGFydHktYXV0aHotMDEudHh0DQo+IA0KPiBPbmUg b3RoZXIgY29tbWVudCB0aGF0IEkgaGF2ZSBhYm91dCB0aGUgcHJvcG9zYWwgaXMgdGhhdCBJIHRo aW5rIHRoZSBtYWMgZm9yIHRoZQ0KPiB0b2tlbiBzaG91bGQgY292ZXIgdGhlIGVuY3J5cHRlZCB0 b2tlbiwgcmF0aGVyIHRoYW4gdGhlIGVuY3J5cHRpb24gY292ZXJpbmcgdGhlDQo+IG1hYy4gU28s IHRoaXMgLi4uDQo+IA0KPiAgICAgICAgICAgc3RydWN0IHsNCj4gICAgICAgICAgICAgICB1c2hv cnQga2V5X2xlbmd0aDsNCj4gICAgICAgICAgICAgICBvcGFxdWUgbWFjX2tleVtrZXlfbGVuZ3Ro XTsNCj4gICAgICAgICAgICAgICBvcGFxdWUgdGltZXN0YW1wWzhdOw0KPiAgICAgICAgICAgICAg IGxvbmcgICBsaWZldGltZTsNCj4gICAgICAgICAgICAgICBvcGFxdWUgbWFjWzE2XTsNCj4gICAg ICAgICAgIH0gdG9rZW47DQo+IA0KPiB3b3VsZCBiZWNvbWUgdGhpcyAuLi4NCj4gDQo+ICAgICAg ICAgICBzdHJ1Y3Qgew0KPiAgICAgICAgICAgICAgIG9wYXF1ZSB7DQo+ICAgICAgICAgICAgICAg ICAgIHVzaG9ydCBrZXlfbGVuZ3RoOw0KPiAgICAgICAgICAgICAgICAgICBvcGFxdWUgbWFjX2tl eVtrZXlfbGVuZ3RoXTsNCj4gICAgICAgICAgICAgICAgICAgb3BhcXVlIHRpbWVzdGFtcFs4XTsN Cj4gICAgICAgICAgICAgICAgICAgbG9uZyAgIGxpZmV0aW1lOw0KPiAgICAgICAgICAgICAgIH0g ZW5jcnlwdGVkX2Jsb2NrOw0KPiAgICAgICAgICAgICAgIG9wYXF1ZSBtYWNbMTZdOw0KPiAgICAg ICAgICAgfSB0b2tlbjsNCj4gDQo+IFRoaXMgbWF5IGluY3JlYXNlIHRoZSBzaXplIG9mIHRoZSBy ZXN1bHRpbmcgdG9rZW4sIGJ1dCBvbmx5IGJ5IGEgc21hbGwgYW1vdW50IChhdA0KPiBtb3N0IDE2 IGJ5dGVzKS4NCg0KV29ya3MgZm9yIG1lLCB3aWxsIHVwZGF0ZSB0aGUgdG9rZW4gZm9ybWF0IGlu IHRoZSBuZXh0IHJldmlzaW9uLg0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQotVGlydQ0KDQo+IA0K PiAtLUJyYW5kb24NCj4gDQo+IE9uIDA0LzIzLzIwMTQgMTA6NTcgQU0sIFRpcnVtYWxlc3dhciBS ZWRkeSAodGlyZWRkeSkgd3JvdGU6DQo+ID4gUmV2aXNlZCBkcmFmdC1yZWRkeS10cmFtLXR1cm4t dGhpcmQtcGFydHktYXV0aHogaGFzIGJlZW4gcHVibGlzaGVkLiBNYWpvcg0KPiBjaGFuZ2UgaXMg dGhhdCBpdOKAmXMgbm93IHVzaW5nIHNlbGYtY29udGFpbmVkIHRva2VuIGFuZCBhZGRyZXNzZXMg dGhlIGNvbW1lbnRzDQo+IHJlY2VpdmVkIGZyb20gdGhlIFdHLg0KPiA+IEZ1cnRoZXIgY29tbWVu dHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KPiA+DQo+ID4gVGhhbmtzIGFuZCBSZWdh cmRzLA0KPiA+IC1BdXRob3JzDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4gPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDIzLCAyMDE0IDc6NDAgUE0N Cj4gPiBUbzogUmFtIE1vaGFuIFIgKHJtb2hhbnIpOyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRp KTsgVGlydW1hbGVzd2FyDQo+ID4gUmVkZHkgKHRpcmVkZHkpOyBQcmFzaGFudGggUGF0aWwgKHBy YXNwYXRpKTsgSnVzdGluIFViZXJ0aTsgSnVzdGluDQo+ID4gVWJlcnRpOyBUaXJ1bWFsZXN3YXIg UmVkZHkgKHRpcmVkZHkpOyBSYW0gTW9oYW4gUiAocm1vaGFucikNCj4gPiBTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJk LXBhcnR5LWF1dGh6LTAxLnR4dA0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAxLnR4dA0KPiA+IGhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJlZGR5IGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6CQlkcmFmdC1yZWRk eS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHoNCj4gPiBSZXZpc2lvbjoJMDENCj4gPiBUaXRs ZToJCVRVUk4gRXh0ZW5zaW9uIGZvciBUaGlyZCBQYXJ0eSBBdXRob3JpemF0aW9uDQo+ID4gRG9j dW1lbnQgZGF0ZToJMjAxNC0wNC0yMw0KPiA+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+ID4gUGFnZXM6CQkxNA0KPiA+IFVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtDQo+IHBhcnR5LWF1 dGh6LTAxLnR4dA0KPiA+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtDQo+IHBhcnR5LWF1dGh6Lw0KPiA+ IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS10 cmFtLXR1cm4tdGhpcmQtcGFydHktDQo+IGF1dGh6LTAxDQo+ID4gRGlmZjogICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXJlZGR5LXRyYW0tdHVybi10aGly ZC1wYXJ0eS0NCj4gYXV0aHotMDENCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgICBUaGlzIGRv Y3VtZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgT0F1dGggdG8gb2J0YWluIGFuZCB2YWxpZGF0ZQ0K PiA+ICAgICBlcGhlbWVyYWwgdG9rZW5zIHRoYXQgY2FuIGJlIHVzZWQgZm9yIFRVUk4gYXV0aGVu dGljYXRpb24uICBUaGUgdXNhZ2UNCj4gPiAgICAgb2YgZXBoZW1lcmFsIHRva2VucyBlbnN1cmUg dGhhdCBhY2Nlc3MgdG8gYSBUVVJOIHNlcnZlciBjYW4gYmUNCj4gPiAgICAgY29udHJvbGxlZCBl dmVuIGlmIHRoZSB0b2tlbnMgYXJlIGNvbXByb21pc2VkLCBhcyBpcyB0aGUgY2FzZSBpbg0KPiA+ ICAgICBXZWJSVEMgd2hlcmUgVFVSTiBjcmVkZW50aWFscyBtdXN0IGJlIHNwZWNpZmllZCBpbiBK YXZhc2NyaXB0Lg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KPiA+DQo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdHJhbSBt YWlsaW5nIGxpc3QNCj4gPiB0cmFtQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmFtDQo+ID4NCj4gDQo+IC0tDQo+IEJyYW5kb24gV2lsbGlhbXM7 IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcgUHJvZHVjdHMNCj4g RW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdHJhbSBtYWlsaW5nIGxpc3QN Cj4gdHJhbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyYW0NCg== From nobody Fri Apr 25 11:06:03 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D951A0687 for ; Fri, 25 Apr 2014 11:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] 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 PjIDbyxuI7WY for ; Fri, 25 Apr 2014 11:05:50 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 39E6A1A05C3 for ; Fri, 25 Apr 2014 11:05:50 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C5B1747442 for ; Fri, 25 Apr 2014 18:05:43 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 3554747422 for ; Fri, 25 Apr 2014 18:05:34 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 2A92CFE054 for ; Fri, 25 Apr 2014 18:05:34 +0000 (GMT) Message-ID: <535AA3EE.9060605@akamai.com> Date: Fri, 25 Apr 2014 14:05:34 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A2431B044@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2431B044@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xM9h75_NCtyvInqD-O6wjfuOkyk Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 18:05:57 -0000 I was referring to the POST body in Section 3 of the current draft. Do you intend to change that section of the draft? Or did you intend that to be an example of what the token request might look like? --Brandon On 04/25/2014 10:14 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Thursday, April 24, 2014 8:29 PM >> To: tram@ietf.org >> Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn- >> third-party-authz-01.txt >> >> The current revision requires a unique key identifier (kid) per TURN server that >> will be shared between the authorization aerver and the TURN server. This has >> some drawbacks for 3rd party TURN service providers and their customers that I >> have some concerns about, the primary one being that the authorization server >> must maintain a key pair for each individual TURN server deployed by the TURN >> service provider. This adds complexity to the problem of deploying new TURN >> server capacity and compounds the problem of key rotation by increasing the >> number of keys. >> Additionally, it increases allocation establishment time by requiring the client to >> learn the correct kid from the TURN server in order to send the kid to the auth >> server in its token request. The client cannot optimize allocation because it is >> required to have access to the kid before contacting that auth server for a >> token. > > No, the client need not have to learn the kid from the TURN server nor needs to send it to the authorization server. Since the kid is unique per TURN server, the client needs to only convey the TURN server IP address to the authorization server when requesting the token. The authorization server identifies the keying material using the TURN server IP address and returns the self-contained token, mac_key, kid, expires_in etc. Client has to pass the kid and self-contained token to the TURN server for authorization. I don't see any increase in the allocation establishment time because of using kid. > > -Tiru > >> >> An alternative is for the auth server and the TURN service to share a single key >> pair, with any individual TURN server being able to decrypt and authenticate the >> token. This allows the TURN service provider to provision new relay capacity >> without any direct interaction with the auth server, and it also means that there >> is only one pre-shared keypair to be managed between the auth server and the >> TURN service. >> >> One shortcoming of this approach is that a single token could be considered >> valid by multiple TURN servers, and thus used by a compromised client to >> establish multiple allocations when only a single one was authorized. This risk is >> easily mitigated by requiring the client to send the relay server's IP address within >> the token request to the auth server (in place of the kid) and for the mac field >> within the encrypted token to include the server's IP address as part of the >> authenticated data. This would make the token's mac valid for just the intended >> receiver without increasing the size of the token. >> >> Another shortcoming of this approach is that compromise of one keypair is a >> global compromise, rather than just compromise of a single TURN relay. This risk >> is easily mitigated through relay-side monitoring/rate-limiting and the ability to >> manually rotate keys. >> >> Are there other shortcomings of this proposed change that I'm not thinking of? >> And do the mitigations that I describe seem reasonable? >> >> Thanks, >> --Brandon >> >> On 04/23/2014 10:57 AM, Tirumaleswar Reddy (tireddy) wrote: >>> Revised draft-reddy-tram-turn-third-party-authz has been published. Major >> change is that it’s now using self-contained token and addresses the comments >> received from the WG. >>> Further comments and suggestions are welcome. >>> >>> Thanks and Regards, >>> -Authors >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Wednesday, April 23, 2014 7:40 PM >>> To: Ram Mohan R (rmohanr); Prashanth Patil (praspati); Tirumaleswar >>> Reddy (tireddy); Prashanth Patil (praspati); Justin Uberti; Justin >>> Uberti; Tirumaleswar Reddy (tireddy); Ram Mohan R (rmohanr) >>> Subject: New Version Notification for >>> draft-reddy-tram-turn-third-party-authz-01.txt >>> >>> >>> A new version of I-D, draft-reddy-tram-turn-third-party-authz-01.txt >>> has been successfully submitted by Tirumaleswar Reddy and posted to the IETF >> repository. >>> >>> Name: draft-reddy-tram-turn-third-party-authz >>> Revision: 01 >>> Title: TURN Extension for Third Party Authorization >>> Document date: 2014-04-23 >>> Group: Individual Submission >>> Pages: 14 >>> URL: http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-third- >> party-authz-01.txt >>> Status: https://datatracker.ietf.org/doc/draft-reddy-tram-turn-third- >> party-authz/ >>> Htmlized: http://tools.ietf.org/html/draft-reddy-tram-turn-third-party- >> authz-01 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-reddy-tram-turn-third-party- >> authz-01 >>> >>> Abstract: >>> This document proposes the use of OAuth to obtain and validate >>> ephemeral tokens that can be used for TURN authentication. The usage >>> of ephemeral tokens ensure that access to a TURN server can be >>> controlled even if the tokens are compromised, as is the case in >>> WebRTC where TURN credentials must be specified in Javascript. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Apr 25 23:15:18 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EB01A041A for ; Fri, 25 Apr 2014 23:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 d1tveKL4pUk1 for ; Fri, 25 Apr 2014 23:15:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AB8B41A01EE for ; Fri, 25 Apr 2014 23:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9850; q=dns/txt; s=iport; t=1398492906; x=1399702506; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VCjAYcf03eqlMgrhZTSmAzJG0XYYEBnYgbwhqPiQVbs=; b=K9CokH6Zwv/YxvXdkplCbmxLJmCl04bPWR4t6iGmOGwoVyItDK7cXUfq BZVUfQavxmzg2baoxW+s6+Ya3JUifLOHOEDRbiBQeRGK1DFjc5z6LO8eK R10MYrjD6i9jKlHA3uOxZvub+PwVeyg/IuGX7/QkPdyFQ+EMc62+WVyfj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIHAHtOW1OtJA2L/2dsb2JhbABZgwZPUQaCZbo6hzgZdhZ0giUBAQEDAQEBASAROgkHBwQCAQgOAwQBAQECAgYdAwICAiULFAEHAQgBAQQBEggBiDAICAWnFqM9F4EpjE0yCwsiBoJpNYEVBJUZhSuRI4FygT+BayQc X-IronPort-AV: E=Sophos;i="4.97,932,1389744000"; d="scan'208";a="320510211" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP; 26 Apr 2014 06:15:05 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3Q6F5q5006364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Apr 2014 06:15:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Sat, 26 Apr 2014 01:15:05 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt Thread-Index: Ac9gkJhkWMtc8Ab9QESd9WUP4nyc/wAShXgAAA7TYFA= Date: Sat, 26 Apr 2014 06:15:04 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431B4D6@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2431B044@xmb-rcd-x10.cisco.com> <535AA3A0.5010702@akamai.com> In-Reply-To: <535AA3A0.5010702@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.61.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/hG4ROzuJhKUbtqz7z4eiF0JO0WM Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 06:15:16 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86Ym93aWxsQGFrYW1haS5jb21dDQo+IFNlbnQ6IEZyaWRheSwgQXByaWwgMjUsIDIwMTQg MTE6MzQgUE0NCj4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IHRyYW1AaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFt0cmFtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1yZWRkeS10cmFtLXR1cm4tDQo+IHRoaXJkLXBhcnR5LWF1dGh6LTAxLnR4dA0KPiAN Cj4gSSB3YXMgcmVmZXJyaW5nIHRvIHRoZSBQT1NUIGJvZHkgaW4gU2VjdGlvbiAzIG9mIHRoZSBj dXJyZW50IGRyYWZ0LiBEbyB5b3UgaW50ZW5kDQo+IHRvIGNoYW5nZSB0aGF0IHNlY3Rpb24gb2Yg dGhlIGRyYWZ0PyANCg0KPiBPciBkaWQgeW91IGludGVuZCB0aGF0IHRvIGJlIGFuIGV4YW1wbGUg b2Ygd2hhdCB0aGUgdG9rZW4gcmVxdWVzdCBtaWdodCBsb29rIGxpa2U/DQoNClllcywgaXQncyBl eGFtcGxlIG9mIHdoYXQgdG9rZW4gcmVxdWVzdCBtaWdodCBsb29rIGxpa2UuIEJ1dCB3aWxsIHVw ZGF0ZSB0aGUgZXhhbXBsZSBhbmQgcmVtb3ZlIGtpZCBmcm9tIFBPU1QgYm9keS4gICBHb29kIGNh dGNoLg0KDQpDaGVlcnMsDQotVGlydQ0KDQo+IA0KPiAtLUJyYW5kb24NCj4gDQo+IE9uIDA0LzI1 LzIwMTQgMTA6MTQgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgd3JvdGU6DQo+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IHRyYW0gW21haWx0bzp0cmFt LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmFuZG9uDQo+ID4+IFdpbGxpYW1zDQo+ ID4+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyNCwgMjAxNCA4OjI5IFBNDQo+ID4+IFRvOiB0cmFt QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3INCj4gPj4gZHJhZnQtcmVkZHktdHJhbS10dXJuLSB0aGlyZC1wYXJ0eS1hdXRo ei0wMS50eHQNCj4gPj4NCj4gPj4gVGhlIGN1cnJlbnQgcmV2aXNpb24gcmVxdWlyZXMgYSB1bmlx dWUga2V5IGlkZW50aWZpZXIgKGtpZCkgcGVyIFRVUk4NCj4gPj4gc2VydmVyIHRoYXQgd2lsbCBi ZSBzaGFyZWQgYmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbiBhZXJ2ZXIgYW5kIHRoZQ0KPiA+PiBU VVJOIHNlcnZlci4gVGhpcyBoYXMgc29tZSBkcmF3YmFja3MgZm9yIDNyZCBwYXJ0eSBUVVJOIHNl cnZpY2UNCj4gPj4gcHJvdmlkZXJzIGFuZCB0aGVpciBjdXN0b21lcnMgdGhhdCBJIGhhdmUgc29t ZSBjb25jZXJucyBhYm91dCwgdGhlDQo+ID4+IHByaW1hcnkgb25lIGJlaW5nIHRoYXQgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIG11c3QgbWFpbnRhaW4gYSBrZXkNCj4gPj4gcGFpciBmb3IgZWFj aCBpbmRpdmlkdWFsIFRVUk4gc2VydmVyIGRlcGxveWVkIGJ5IHRoZSBUVVJOIHNlcnZpY2UNCj4g Pj4gcHJvdmlkZXIuIFRoaXMgYWRkcyBjb21wbGV4aXR5IHRvIHRoZSBwcm9ibGVtIG9mIGRlcGxv eWluZyBuZXcgVFVSTg0KPiA+PiBzZXJ2ZXIgY2FwYWNpdHkgYW5kIGNvbXBvdW5kcyB0aGUgcHJv YmxlbSBvZiBrZXkgcm90YXRpb24gYnkgaW5jcmVhc2luZyB0aGUNCj4gbnVtYmVyIG9mIGtleXMu DQo+ID4+IEFkZGl0aW9uYWxseSwgaXQgaW5jcmVhc2VzIGFsbG9jYXRpb24gZXN0YWJsaXNobWVu dCB0aW1lIGJ5IHJlcXVpcmluZw0KPiA+PiB0aGUgY2xpZW50IHRvIGxlYXJuIHRoZSBjb3JyZWN0 IGtpZCBmcm9tIHRoZSBUVVJOIHNlcnZlciBpbiBvcmRlciB0bw0KPiA+PiBzZW5kIHRoZSBraWQg dG8gdGhlIGF1dGggc2VydmVyIGluIGl0cyB0b2tlbiByZXF1ZXN0LiBUaGUgY2xpZW50DQo+ID4+ IGNhbm5vdCBvcHRpbWl6ZSBhbGxvY2F0aW9uIGJlY2F1c2UgaXQgaXMgcmVxdWlyZWQgdG8gaGF2 ZSBhY2Nlc3MgdG8NCj4gPj4gdGhlIGtpZCBiZWZvcmUgY29udGFjdGluZyB0aGF0IGF1dGggc2Vy dmVyIGZvciBhIHRva2VuLg0KPiA+DQo+ID4gTm8sIHRoZSBjbGllbnQgbmVlZCBub3QgaGF2ZSB0 byBsZWFybiB0aGUga2lkIGZyb20gdGhlIFRVUk4gc2VydmVyIG5vciBuZWVkcw0KPiB0byBzZW5k IGl0IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gU2luY2UgdGhlIGtpZCBpcyB1bmlxdWUg cGVyIFRVUk4gc2VydmVyLA0KPiB0aGUgY2xpZW50IG5lZWRzIHRvIG9ubHkgY29udmV5IHRoZSBU VVJOIHNlcnZlciBJUCBhZGRyZXNzIHRvIHRoZSBhdXRob3JpemF0aW9uDQo+IHNlcnZlciB3aGVu IHJlcXVlc3RpbmcgdGhlIHRva2VuLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaWRlbnRpZmll cyB0aGUga2V5aW5nDQo+IG1hdGVyaWFsIHVzaW5nIHRoZSBUVVJOIHNlcnZlciBJUCBhZGRyZXNz IGFuZCByZXR1cm5zIHRoZSBzZWxmLWNvbnRhaW5lZCB0b2tlbiwNCj4gbWFjX2tleSwga2lkLCBl eHBpcmVzX2luIGV0Yy4gIENsaWVudCBoYXMgdG8gcGFzcyB0aGUga2lkIGFuZCBzZWxmLWNvbnRh aW5lZCB0b2tlbg0KPiB0byB0aGUgVFVSTiBzZXJ2ZXIgZm9yIGF1dGhvcml6YXRpb24uIEkgZG9u J3Qgc2VlIGFueSBpbmNyZWFzZSBpbiB0aGUgYWxsb2NhdGlvbg0KPiBlc3RhYmxpc2htZW50IHRp bWUgYmVjYXVzZSBvZiB1c2luZyBraWQuDQo+ID4NCj4gPiAtVGlydQ0KPiA+DQo+ID4+DQo+ID4+ IEFuIGFsdGVybmF0aXZlIGlzIGZvciB0aGUgYXV0aCBzZXJ2ZXIgYW5kIHRoZSBUVVJOIHNlcnZp Y2UgdG8gc2hhcmUgYQ0KPiA+PiBzaW5nbGUga2V5IHBhaXIsIHdpdGggYW55IGluZGl2aWR1YWwg VFVSTiBzZXJ2ZXIgYmVpbmcgYWJsZSB0bw0KPiA+PiBkZWNyeXB0IGFuZCBhdXRoZW50aWNhdGUg dGhlIHRva2VuLiBUaGlzIGFsbG93cyB0aGUgVFVSTiBzZXJ2aWNlDQo+ID4+IHByb3ZpZGVyIHRv IHByb3Zpc2lvbiBuZXcgcmVsYXkgY2FwYWNpdHkgd2l0aG91dCBhbnkgZGlyZWN0DQo+ID4+IGlu dGVyYWN0aW9uIHdpdGggdGhlIGF1dGggc2VydmVyLCBhbmQgaXQgYWxzbyBtZWFucyB0aGF0IHRo ZXJlIGlzDQo+ID4+IG9ubHkgb25lIHByZS1zaGFyZWQga2V5cGFpciB0byBiZSBtYW5hZ2VkIGJl dHdlZW4gdGhlIGF1dGggc2VydmVyIGFuZCB0aGUNCj4gVFVSTiBzZXJ2aWNlLg0KPiA+Pg0KPiA+ PiBPbmUgc2hvcnRjb21pbmcgb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0IGEgc2luZ2xlIHRva2Vu IGNvdWxkIGJlDQo+ID4+IGNvbnNpZGVyZWQgdmFsaWQgYnkgbXVsdGlwbGUgVFVSTiBzZXJ2ZXJz LCBhbmQgdGh1cyB1c2VkIGJ5IGENCj4gPj4gY29tcHJvbWlzZWQgY2xpZW50IHRvIGVzdGFibGlz aCBtdWx0aXBsZSBhbGxvY2F0aW9ucyB3aGVuIG9ubHkgYQ0KPiA+PiBzaW5nbGUgb25lIHdhcyBh dXRob3JpemVkLiBUaGlzIHJpc2sgaXMgZWFzaWx5IG1pdGlnYXRlZCBieSByZXF1aXJpbmcNCj4g Pj4gdGhlIGNsaWVudCB0byBzZW5kIHRoZSByZWxheSBzZXJ2ZXIncyBJUCBhZGRyZXNzIHdpdGhp biB0aGUgdG9rZW4NCj4gPj4gcmVxdWVzdCB0byB0aGUgYXV0aCBzZXJ2ZXIgKGluIHBsYWNlIG9m IHRoZSBraWQpIGFuZCBmb3IgdGhlIG1hYw0KPiA+PiBmaWVsZCB3aXRoaW4gdGhlIGVuY3J5cHRl ZCB0b2tlbiB0byBpbmNsdWRlIHRoZSBzZXJ2ZXIncyBJUCBhZGRyZXNzDQo+ID4+IGFzIHBhcnQg b2YgdGhlIGF1dGhlbnRpY2F0ZWQgZGF0YS4gVGhpcyB3b3VsZCBtYWtlIHRoZSB0b2tlbidzIG1h YyB2YWxpZCBmb3INCj4ganVzdCB0aGUgaW50ZW5kZWQgcmVjZWl2ZXIgd2l0aG91dCBpbmNyZWFz aW5nIHRoZSBzaXplIG9mIHRoZSB0b2tlbi4NCj4gPj4NCj4gPj4gQW5vdGhlciBzaG9ydGNvbWlu ZyBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgY29tcHJvbWlzZSBvZiBvbmUNCj4gPj4ga2V5cGFp ciBpcyBhIGdsb2JhbCBjb21wcm9taXNlLCByYXRoZXIgdGhhbiBqdXN0IGNvbXByb21pc2Ugb2Yg YQ0KPiA+PiBzaW5nbGUgVFVSTiByZWxheS4gVGhpcyByaXNrIGlzIGVhc2lseSBtaXRpZ2F0ZWQg dGhyb3VnaCByZWxheS1zaWRlDQo+ID4+IG1vbml0b3JpbmcvcmF0ZS1saW1pdGluZyBhbmQgdGhl IGFiaWxpdHkgdG8gbWFudWFsbHkgcm90YXRlIGtleXMuDQo+ID4+DQo+ID4+IEFyZSB0aGVyZSBv dGhlciBzaG9ydGNvbWluZ3Mgb2YgdGhpcyBwcm9wb3NlZCBjaGFuZ2UgdGhhdCBJJ20gbm90IHRo aW5raW5nDQo+IG9mPw0KPiA+PiBBbmQgZG8gdGhlIG1pdGlnYXRpb25zIHRoYXQgSSBkZXNjcmli ZSBzZWVtIHJlYXNvbmFibGU/DQo+ID4+DQo+ID4+IFRoYW5rcywNCj4gPj4gLS1CcmFuZG9uDQo+ ID4+DQo+ID4+IE9uIDA0LzIzLzIwMTQgMTA6NTcgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkgd3JvdGU6DQo+ID4+PiBSZXZpc2VkIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi10aGlyZC1w YXJ0eS1hdXRoeiBoYXMgYmVlbiBwdWJsaXNoZWQuDQo+ID4+PiBNYWpvcg0KPiA+PiBjaGFuZ2Ug aXMgdGhhdCBpdOKAmXMgbm93IHVzaW5nIHNlbGYtY29udGFpbmVkIHRva2VuIGFuZCBhZGRyZXNz ZXMgdGhlDQo+ID4+IGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gdGhlIFdHLg0KPiA+Pj4gRnVydGhl ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQo+ID4+Pg0KPiA+Pj4gVGhh bmtzIGFuZCBSZWdhcmRzLA0KPiA+Pj4gLUF1dGhvcnMNCj4gPj4+DQo+ID4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+Pj4gU2VudDogV2VkbmVzZGF5LCBB cHJpbCAyMywgMjAxNCA3OjQwIFBNDQo+ID4+PiBUbzogUmFtIE1vaGFuIFIgKHJtb2hhbnIpOyBQ cmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVzd2FyDQo+ID4+PiBSZWRkeSAodGly ZWRkeSk7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBKdXN0aW4gVWJlcnRpOyBKdXN0aW4N Cj4gPj4+IFViZXJ0aTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgUmFtIE1vaGFuIFIg KHJtb2hhbnIpDQo+ID4+PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ ID4+PiBkcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDEudHh0DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yZWRkeS10cmFtLXR1 cm4tdGhpcmQtcGFydHktYXV0aHotMDEudHh0DQo+ID4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvDQo+ID4+PiB0aGUg SUVURg0KPiA+PiByZXBvc2l0b3J5Lg0KPiA+Pj4NCj4gPj4+IE5hbWU6CQlkcmFmdC1yZWRkeS10 cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHoNCj4gPj4+IFJldmlzaW9uOgkwMQ0KPiA+Pj4gVGl0 bGU6CQlUVVJOIEV4dGVuc2lvbiBmb3IgVGhpcmQgUGFydHkgQXV0aG9yaXphdGlvbg0KPiA+Pj4g RG9jdW1lbnQgZGF0ZToJMjAxNC0wNC0yMw0KPiA+Pj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCj4gPj4+IFBhZ2VzOgkJMTQNCj4gPj4+IFVSTDogICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtDQo+ ID4+IHBhcnR5LWF1dGh6LTAxLnR4dA0KPiA+Pj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi10aGlyZC0NCj4gPj4g cGFydHktYXV0aHovDQo+ID4+PiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJkLXBhcnR5LQ0KPiA+PiBhdXRoei0wMQ0K PiA+Pj4gRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LXJlZGR5LXRyYW0tdHVybi10aGlyZC0NCj4gcGFydHktDQo+ID4+IGF1dGh6LTAxDQo+ID4+ Pg0KPiA+Pj4gQWJzdHJhY3Q6DQo+ID4+PiAgICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhl IHVzZSBvZiBPQXV0aCB0byBvYnRhaW4gYW5kIHZhbGlkYXRlDQo+ID4+PiAgICAgIGVwaGVtZXJh bCB0b2tlbnMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgVFVSTiBhdXRoZW50aWNhdGlvbi4gIFRoZSB1 c2FnZQ0KPiA+Pj4gICAgICBvZiBlcGhlbWVyYWwgdG9rZW5zIGVuc3VyZSB0aGF0IGFjY2VzcyB0 byBhIFRVUk4gc2VydmVyIGNhbiBiZQ0KPiA+Pj4gICAgICBjb250cm9sbGVkIGV2ZW4gaWYgdGhl IHRva2VucyBhcmUgY29tcHJvbWlzZWQsIGFzIGlzIHRoZSBjYXNlIGluDQo+ID4+PiAgICAgIFdl YlJUQyB3aGVyZSBUVVJOIGNyZWRlbnRpYWxzIG11c3QgYmUgc3BlY2lmaWVkIGluIEphdmFzY3Jp cHQuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPj4+IHN1 Ym1pc3Npb24NCj4gPj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPj4+DQo+ID4+PiBUaGUgSUVURiBTZWNyZXRh cmlhdA0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+PiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+Pj4gdHJhbUBpZXRmLm9yZw0K PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo+ID4+Pg0K PiA+Pg0KPiA+PiAtLQ0KPiA+PiBCcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNv ZnR3YXJlIEVuZ2luZWVyIEVtZXJnaW5nDQo+ID4+IFByb2R1Y3RzIEVuZ2luZWVyaW5nOyBBa2Ft YWkgVGVjaG5vbG9naWVzIEluYy4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gPj4gdHJh bUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry YW0NCj4gDQo+IC0tDQo+IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdh cmUgRW5naW5lZXIgRW1lcmdpbmcgUHJvZHVjdHMNCj4gRW5naW5lZXJpbmc7IEFrYW1haSBUZWNo bm9sb2dpZXMgSW5jLg0K From nobody Tue Apr 29 05:42:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495BA1A08BB for ; Tue, 29 Apr 2014 05:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 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.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 FHF8nWahhJC2 for ; Tue, 29 Apr 2014 05:42:23 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 71A461A08CE for ; Tue, 29 Apr 2014 05:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3531; q=dns/txt; s=iport; t=1398775332; x=1399984932; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=L7P8s1jK2wmz/GjnrQnLOdaY028fEGttz9DRjvS9WmQ=; b=ZfgxFXpDU1jWmuy2rRXmZxcix1CgUP9Tp96UiTexnL+03s2roCAJBX4k pjXgFIaDQ4IFqVqmuaQzKy9Ry3f7dGgdNZZAnZ7ZkpTN9tmeczkmEWNjI r3PbMKZyS3v/k8Mh3sPGEqCWbu3CweDQ19Cl23qIu0TMtXG29y7eCisNk M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAHCdX1OtJA2F/2dsb2JhbABPCoMGT1e9PYc5gSAWdIIlAQEBBAEBASZFGwIBAgYYLiEGCyUCBAESCYgkAxENwmkNhjQXjDiBO2OEOQSJOo1mgXCNDYVVgXKBP4Ir X-IronPort-AV: E=Sophos;i="4.97,951,1389744000"; d="scan'208";a="39640834" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP; 29 Apr 2014 12:42:09 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s3TCg9gl008155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Apr 2014 12:42:09 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.202]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 29 Apr 2014 07:42:08 -0500 From: "Prashanth Patil (praspati)" To: "Gonzalo Salgueiro (gsalguei)" , "tram@ietf.org" Thread-Topic: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] Thread-Index: AQHPY6huGB9DPNq7+Ee36CyaTwlSZA== Importance: high X-Priority: 1 Date: Tue, 29 Apr 2014 12:42:07 +0000 Message-ID: References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> <533E8283.7030509@acm.org> <533EB57F.6020707@viagenie.ca> <372E2E90-DCCC-4500-A67E-2246ED3DCC39@cisco.com> <533EF340.40800@viagenie.ca> <8960BF8C-F45C-47D9-81F7-8D1F4F101324@cisco.com> <18C1CCED-887D-4A56-BEC2-3B2FE7B99482@cisco.com> In-Reply-To: <18C1CCED-887D-4A56-BEC2-3B2FE7B99482@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [64.103.236.131] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <56C5C2EEFD9A5E4A895E6978AC39EBD6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/jSL0puP4PXvHAXr99JvhdvF4FRQ Subject: Re: [tram] ALPN Registration [was Re: I-D Action: draft-ietf-tram-stun-dtls-01.txt] X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 12:42:35 -0000 Submitted draft is=20 http://www.ietf.org/internet-drafts/draft-patil-tram-alpn-00.txt -Prashanth On 4/22/14 7:34 PM, "Gonzalo Salgueiro (gsalguei)" wrote: >Apologize for the delay (day job and stuff...), but based on this >discussion, we have just submitted a draft registering a STUN ALPN >protocol identifier. Review comments welcome. > >There are two things we need WG direction on: > >(1) We have an open item that requires discussion: > =20 > In various offline discussions some have expressed a desire > to add an additional ALPN protocol identifier for TURN (see IANA > Considerations below for example registration). ALPN can be used > more granularly to externally identify more of the protocol variants > and their different properties (i.e., STUN and TURN over TLS/DTLS). > The advantage in dividing it this way is that these different forms > can be externally identified (obviously, there isn't any inherent > value in the different identifiers from within the TLS > handshake).There are two main disadvantages. the first is that this > two application protocol approach may make implementations more > complicated/confusing. The second is that there may be difficulty in > differentiating the two with ALPN when TURN was specifically designed > to be able to run on the same port as STUN usage (in section 13 of > RFC 5389). Section 4.1.1.2 of RFC 5245 explicitly says that "If the > Allocate request is rejected because the server lacks resources to > fulfill it, the agent SHOULD instead send a Binding request to obtain > a server reflexive candidate." Does that prove there is no need to > differentiate TURN and STUN request on UDP/TCP or TLS and now DTLS? > Are there sufficiently meaningful differences between the usages to > warrant separate STUN and TURN ALPN identifiers? > >(2) How do we progress this draft? Create a new milestone and adopt as a >TRAM WG item or is best handled as an AD-sponsored individual draft? > > >Thanks, > >Gonzalo > > > >On Apr 4, 2014, at 4:17 PM, Oleg Moskalenko wrote: > >> If ALPN is really independent of DTLS, I see no reason why they have to >>be combined in the draft document that was created solely for the DTLS >>feature introduction for STUNl. >>=20 >>=20 >> On Fri, Apr 4, 2014 at 11:09 AM, Gonzalo Salgueiro (gsalguei) >> wrote: >>=20 >> On Apr 4, 2014, at 2:00 PM, Simon Perreault >> wrote: >>=20 >> > Le 2014-04-04 13:58, Gonzalo Salgueiro (gsalguei) a =E9crit : >> >> Understood. Nonetheless, even if not a part of STUNbis, it doesn't >>seem it should be buried in STUNoDTLS. Shall we produce a dedicated >>draft for this? >> > >> > My preference would be for "buried in STUNoDTLS". :) But I'm open to >>arguments for a dedicated draft. >>=20 >> My position is that the ALPN reg is entirely independent of STUNoDTLS, >>which is why we considered more contextually relevant for the broader >>STUNbis effort. A standalone dedicated ALPN reg doc to point to seems >>cleaner to me, but I'm open to WG decision on this. >>=20 >> -G >>=20 >> > >> > Simon >>=20 >> _______________________________________________ >> 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 nobody Tue Apr 29 19:15:45 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41481A093E for ; Tue, 29 Apr 2014 19:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 eHSa0sonn1jw for ; Tue, 29 Apr 2014 19:15:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2643D1A0949 for ; Tue, 29 Apr 2014 19:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6013; q=dns/txt; s=iport; t=1398824139; x=1400033739; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=WfcH+FYwBb5T7052Kw3/WMbx1YXwOoWMNhCyLXlq5uY=; b=cMPC5TIYK/y4+vhyqE07sYho2EdfctzqC2YQOl/9qRNoI0AoSvY1pUcz xIt2w6c2ARlJ1gdFFo5aKrwcq9ldu98P0watWSVQ8iCeQIaDMOZ/Zbmsd RnpJfM2ojuBHMrVkoS8W/7XAVnPhj5dqWagdgHMPNdtCHuDM1ykDwV8Dt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAP5bYFOtJV2Y/2dsb2JhbABPCoMGT1e9Loc5gSYWdIIlAQEBAgEBAQEBNzQQBwYBCBEEAQELDgYJLgsUCQkBBAESCAGIMAgNygoXjWMQKz4SgwyBFQSaTJEngzGBcjk X-IronPort-AV: E=Sophos;i="4.97,955,1389744000"; d="scan'208";a="321346965" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 30 Apr 2014 02:15:38 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3U2FcnX007950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 02:15:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 29 Apr 2014 21:15:38 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] Review of draft-ietf-tram-auth-problems-00 Thread-Index: Ac9kGg/YNCKChplNTCa+JC7TIfSJYA== Date: Wed, 30 Apr 2014 02:15:38 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431E0B5@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.70.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Qnp6n0lm1zTOHzHYMnnZ2Ch0Gy0 Subject: Re: [tram] Review of draft-ietf-tram-auth-problems-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 02:15:45 -0000 Hi Marc, Thanks for the review. Please see inline > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit-Hugueni= n > Sent: Friday, April 18, 2014 8:27 PM > To: tram@ietf.org > Subject: [tram] Review of draft-ietf-tram-auth-problems-00 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > A1. 1. Title "Problems with STUN Authentication for TURN >=20 > I would suggest to change the title to "Problems with STUN long-term > Authentication for TURN", as the STUN short-term authentication is not > discussed in this draft. TURN only uses long-term authentication, so > "Problems with TURN Authentication" is fine too. Changed the title to "Problems with STUN long-term Authentication for TURN"= . (The 00 version of the draft had the title "Problems with TURN Authentic= ation" (https://tools.ietf.org/html/draft-reddy-behave-turn-auth-00) but ba= sed on the comments received in BEHAVE WG that TURN is only using the long-= term authentication mechanism provided by STUN, the title of the draft was = changed in 01 version.) >=20 > A2. Section 1. Introduction, first paragraph. >=20 > I think that this paragraph puts too much emphasis on WebRTC. WebRTC > is the reason people are finding issues with the authentication, but > it is not the reason for the issues. Yes, updated the draft. >=20 > A3. Section 2. Notational Conventions >=20 > This is an informational draft, so RFC 2119 key words (and the > reference) do not need to be defined. besides, none of them are used > in the document. Ok, removed. >=20 > A4. Section 4. Title >=20 > Replace with "Problems with usage of long-term STUN Authentication" Ok. >=20 > A5. Section 4, fourth bullet. >=20 > This is an man-in-the-middle attack, so the text should say so. Updated. >=20 > A6. Section 4, 5th bullet >=20 > Note that this applies only to the TCP and UDP transports, as SNI can > be used to select the tenant/realm when TLS or DTLS is used. The need for ORIGIN attribute even if D{TLS} is used is discussed in http:/= /tools.ietf.org/html/draft-johnston-tram-stun-origin-02 >=20 > A7. Section 4, 6th bullet. "This exposes the user credential to the > Javascript which could be malicious". >=20 > It is only a problem if somehow the web server sends a user/password > that can be used to access something else than the TURN server > resources. It is not a problem created by the long-term > authentication, but by bad code or misconfiguration on the server > side. =20 The problem is that long-term credentials (username/password) must be expos= ed to the java script code which could be malicious. For example refer to t= he sample java script code in slide 2 of http://www.ietf.org/proceedings/87= /slides/slides-87-behave-10.pdf where RTCPeerConnection API needs the clien= t username/password. The credentials could be leaked by a malicious java s= cript, thus resulting in TURN server access to be misused.=20 > If you really insist on saying something about this, it should > about how long-term authentication creates the possibility that a web > server sends credentials that can be reused elsewhere. I think that > the 3rd bullet as the same issue: Privacy leakage is not a > consequence of using long-term authentication, but of using usernames > that can be matched with a real person or that can be reused to access > other resources. Agreed. NEW: 3. The long-term credential mechanism in [RFC5389] requires that the TURN client must include username value in the USERNAME STUN attribute. An adversary snooping the TURN messages between the TURN client and server can identify the users involved in the call resulting in privacy leakage. If TURN usernames are linked to real usernames then it will result in privacy leakage, but in certain scenarios TURN usernames need not be linked to any real usernames given to users as they are just provisioned on a per company basis. .... .... 7. In WebRTC the Javascript code needs to know the username and password to use in W3C RTCPeerConnection API to access the TURN server. This exposes the user credentials to the Javascript which could be malicious. The malicious java script could misuse or leak the credentials. If the credentials happen to be used for accessing services other than TURN then the security implications are much larger. >=20 > A7. Section 8. References >=20 > I think that because this is an Informational document, all the > references must be Informative. I think informational document can have normative references. For example c= heck RFC7152, RFC 6819. >=20 >=20 > Nits > =3D=3D=3D=3D >=20 > - - Section 1. 4th bullet "ICE connectivity checks using > server-reflexive candidate" >=20 > The exact terminology in RFC 5245 is "server reflexive". Updated. >=20 > - - Section 4, second paragraph "...is deployed in DMZ..." >=20 > Expand the initialism. Ok. >=20 > - - Section 4, sixth bullet >=20 > s/Javascript needs be know/JavaScript code needs to know/ Fixed. Thanks and Regards, -Tiru > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQEcBAEBAgAGBQJTUT1DAAoJEMUNRP98lsiX2j8IAI887pQ2p5EpzjjjHXHykUe1 > mDfUX1wjs5YO7067sWV0s7gHev5G9h6NIo4fjQ8JNNmng3WkBn6hPT1k3HXz4KE > d > CpHFiihPMvjstjUv6AUtAF4igiRO2V4rkCbiHzxXt268+QTnW3Whzsjlq01pD6Pj > RZcCBE/ASHy+8wUdV+CpF6ZHFU6+165pajiaEusMfrCLAqlin/Rj3aRBBe+s7/s7 > yrHTlsQzEYPKdAvi6qD0MlZ6+/jtari0VJhQA5/fvHsa+3GA6/z9h5nACfXI+yh2 > j9So3/qD90njHQFtxQXvspKasYagZjwO93RxLzIYKVy2BDMHlmsGL7wJ62Vo55o=3D > =3DYfrU > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Apr 30 04:54:36 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE39D1A6EF0 for ; Wed, 30 Apr 2014 04:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 KuW1vMaNhBPu for ; Wed, 30 Apr 2014 04:54:32 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB131A08BD for ; Wed, 30 Apr 2014 04:54:32 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id as1so1768193iec.11 for ; Wed, 30 Apr 2014 04:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=4HpBPIusg6ieTSLZxpq6QlTumYmzD3BJXC5r+S9IxnI=; b=OWbkziE+imi7Nuc96mI+8UFeRng6IUNTkEP7W+oTbTveBfrNhYJob2yo4F0LJ9d9Bv fB4ovn/Xat+hPsRcsFVASBB9ex0/6vtVHgy383TXg8T/5dqGt4n9ZF/zTmqG8IyOUawp EitDCuGzHp8x9AOZtTkhmrlvAMIqve8WrhiDA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=4HpBPIusg6ieTSLZxpq6QlTumYmzD3BJXC5r+S9IxnI=; b=Pj+R6yp//3TWMteghNp+pTuWc+ZV8bezgpogiJeV2to3mLZnmjwK6/EZtR2WJ+wP7q MzMPA4zEExj47Xhp40LQ/EcoW1MeLvsTxJCyolyKI5shW+YpiobF+NJrgFkHJ6CZMJFZ JZ6FFC2Qi0whfCP4lkdtS/ZF2FBFskjC7af7v0SxQtcGPyRqDCD7+6eRpCeNn7fbetLR fid8s1ugtgVf/ApoId3J1pxvCiknts5YikNrsot/g9CmBRp0DZ9XF/D0zaqZtdFeRlz9 Vbc3oGkW8k3vbnQ0eYfTdUKqJNtdsyZN2xVsh5GxLbzlZ/reBg981BNsHOgMbLFskpNs FPSQ== X-Gm-Message-State: ALoCoQklGwfebWJE5cML31VvQNdTYaXpjjsowPZktFcQ+JyLCVPWITK1y1S5i8sYQ15Sq+95yxm5 X-Received: by 10.50.62.51 with SMTP id v19mr37339677igr.21.1398858870038; Wed, 30 Apr 2014 04:54:30 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id vm7sm5277741igb.1.2014.04.30.04.54.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 04:54:29 -0700 (PDT) Message-ID: <5360E46B.8080103@getjive.com> Date: Wed, 30 Apr 2014 05:54:19 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A2431E0B5@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2431E0B5@xmb-rcd-x10.cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ab24ecJTsqxh5A07Mkq872e5nC2mURxD8" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Kd02rPc0Cz91nMKTsbj5ObiccpA Subject: Re: [tram] Review of draft-ietf-tram-auth-problems-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 11:54:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ab24ecJTsqxh5A07Mkq872e5nC2mURxD8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/29/14, 8:15 PM, Tirumaleswar Reddy (tireddy) wrote: > Hi Marc, >=20 > Thanks for the review. Please see inline >=20 >> -----Original Message----- From: tram >> [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin=20 >> Sent: Friday, April 18, 2014 8:27 PM To: tram@ietf.org Subject: >> [tram] Review of draft-ietf-tram-auth-problems-00 >>=20 [...] >=20 > A6. Section 4, 5th bullet >=20 > Note that this applies only to the TCP and UDP transports, as SNI > can be used to select the tenant/realm when TLS or DTLS is used. >=20 >> The need for ORIGIN attribute even if D{TLS} is used is discussed >> in http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02 Right. I did a review (yet to be published) of stun-origin after this on= e. >=20 >=20 > A7. Section 4, 6th bullet. "This exposes the user credential to the=20 > Javascript which could be malicious". >=20 > It is only a problem if somehow the web server sends a user/password=20 > that can be used to access something else than the TURN server=20 > resources. It is not a problem created by the long-term=20 > authentication, but by bad code or misconfiguration on the server=20 > side. >=20 >> The problem is that long-term credentials (username/password) must >> be exposed to the java script code which could be malicious. For >> example refer to the sample java script code in slide 2 of >> http://www.ietf.org/proceedings/87/slides/slides-87-behave-10.pdf >> where RTCPeerConnection API needs the client username/password. >> The credentials could be leaked by a malicious java script, thus >> resulting in TURN server access to be misused. >=20 > If you really insist on saying something about this, it should about > how long-term authentication creates the possibility that a web=20 > server sends credentials that can be reused elsewhere. I think that=20 > the 3rd bullet as the same issue: Privacy leakage is not a=20 > consequence of using long-term authentication, but of using > usernames that can be matched with a real person or that can be > reused to access other resources. >=20 >> Agreed. >=20 >> NEW: >=20 >> 3. The long-term credential mechanism in [RFC5389] requires that >> the TURN client must include username value in the USERNAME STUN=20 >> attribute. An adversary snooping the TURN messages between the=20 >> TURN client and server can identify the users involved in the call >> resulting in privacy leakage. If TURN usernames are linked to real >> usernames then it will result in privacy leakage, but in certain >> scenarios TURN usernames need not be linked to any real usernames >> given to users as they are just provisioned on a per company >> basis. >=20 >> .... .... >=20 >=20 >> 7. In WebRTC the Javascript code needs to know the username and=20 >> password to use in W3C RTCPeerConnection API to access the TURN=20 >> server. This exposes the user credentials to the Javascript which >> could be malicious. The malicious java script could misuse or leak >> the credentials. If the credentials happen to be used for >> accessing services other than TURN then the security implications >> are much larger. That looks fine. >=20 > A7. Section 8. References >=20 > I think that because this is an Informational document, all the=20 > references must be Informative. >=20 >> I think informational document can have normative references. For >> example check RFC7152, RFC 6819. >=20 OK. Thanks. --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --ab24ecJTsqxh5A07Mkq872e5nC2mURxD8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTYORyAAoJEMUNRP98lsiXWokH+wfBMXL8UbKmOzXz2q4KVT0P GcC6+rraMPx/8ddy1h8Mg7vbmy38eFsoRLN5MA0cP1VSwEQGvEjFZoF5w9wBjzqb /CzL9bTDzhQDyKLEg/UGa+4FNm9JJZPy7qF0NyiM8etPEyk/vuR0/s9lL7Acoccr TmG1DfCrmTVggHf3XjNM+IyFYCaop/Q2kWzHKDhkW/B91P3Fx9JZ9yN0t5NQP4AB xykD4T5w3nP2CDc4fuBobHkhQdZZ2/YZE7VuFaGsKqyvqVv57hnXrZCyYeVrlDPA Cf4EmJdUVFBudsj3MDgULYebB1lHhvsi3aZ79GH4OTcVR0H1WgkSNvyxjI1nTYU= =/CfB -----END PGP SIGNATURE----- --ab24ecJTsqxh5A07Mkq872e5nC2mURxD8--