From nobody Thu May 1 06:01:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106251A88F4; Thu, 1 May 2014 06:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hfZ1TfkRbX2z; Thu, 1 May 2014 06:01:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 068E01A07C7; Thu, 1 May 2014 06:01:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140501130111.21603.33018.idtracker@ietfa.amsl.com> Date: Thu, 01 May 2014 06:01:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5he4wdg678HyIhkWsOXCvtXNeLc Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-auth-problems-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 13:01:12 -0000 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 : Problems with STUN long-term Authentication for TURN Authors : Tirumaleswar Reddy Ram Mohan Ravindranath Muthu Arul Mozhi Perumal Alper Yegin Filename : draft-ietf-tram-auth-problems-01.txt Pages : 7 Date : 2014-05-01 Abstract: This document discusses some of the issues with STUN authentication for TURN messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-auth-problems/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-auth-problems-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-auth-problems-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/ From nobody Thu May 1 08:35: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 E36931A0915 for ; Thu, 1 May 2014 08:35:26 -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 vtNW07dpruOT for ; Thu, 1 May 2014 08:35:25 -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 4347E1A073F for ; Thu, 1 May 2014 08:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1856; q=dns/txt; s=iport; t=1398958523; x=1400168123; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k0qv+eW8ZIOKZZAiLtnvBQkTuQ2Fa3b0oiHyqE+ZmDw=; b=LyjbbR+Q9/E5Q3djrf5BRUHxeaESxfVXCs8faBaZ1MWOlPlbxN7BXTOb k2CzDdFLc3TGPrOhHJglPmGLpIpl1xIsnstwy7Npx4PzQHi5iyvllWvhU TJsni9uP1cJIEgZg/+1tBjoQS8t78FWeuWS9/vxBlvzKdP5OvrsmsY8Zf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0HAIFoYlOtJA2E/2dsb2JhbABZgwZPUQa9HYc+gREWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQTCAGIOAgFyiMXjiE4BoMegRUEmmuRMoMzgis X-IronPort-AV: E=Sophos;i="4.97,965,1389744000"; d="scan'208";a="321721453" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 01 May 2014 15:35:22 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s41FZMUS018825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 May 2014 15:35:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 1 May 2014 10:35:22 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-auth-problems-01.txt Thread-Index: AQHPZT1y62oxdrMpKESo1r6Ykhg7cZsrsQvw Date: Thu, 1 May 2014 15:35:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2431F150@xmb-rcd-x10.cisco.com> References: <20140501130111.21603.33018.idtracker@ietfa.amsl.com> In-Reply-To: <20140501130111.21603.33018.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.71.93] 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/4B5PkEt-UKR5dHJ5dIZOHBmZ7iE Subject: Re: [tram] I-D Action: draft-ietf-tram-auth-problems-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, 01 May 2014 15:35:27 -0000 Revised version addresses the comments received from Marc. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, May 01, 2014 6:31 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-auth-problems-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized Working Gro= up > of the IETF. >=20 > Title : Problems with STUN long-term Authentication for= TURN > Authors : Tirumaleswar Reddy > Ram Mohan Ravindranath > Muthu Arul Mozhi Perumal > Alper Yegin > Filename : draft-ietf-tram-auth-problems-01.txt > Pages : 7 > Date : 2014-05-01 >=20 > Abstract: > This document discusses some of the issues with STUN authentication > for TURN messages. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-auth-problems/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-auth-problems-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-auth-problems-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri May 2 03:02:12 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF231A6EDA for ; Fri, 2 May 2014 03:02:10 -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 8GRgnuDUG6Rq for ; Fri, 2 May 2014 03:02:05 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id EC60F1A0A6F for ; Fri, 2 May 2014 03:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2015; q=dns/txt; s=iport; t=1399024923; x=1400234523; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ll2WSCiRq8bE/z7EVi5g3lB8GxGCR7uW68XbwlVreg0=; b=Yy78t5Xfftj7PSVyNshfULhKiQTObCQAS4q/Dkn8tSowLcC2YMz7I8Vi afYYp5wDc5Sb/DEs88jMaTFnq5PLyXrOP2MJSqVwwmqfM6TAvvyQHh8mi 7DAaKivm8h5q1k2eeMlOw6/UaF0ZGnZ2BoO8B94O9a77wMotb1R1syFl+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUGAL1rY1OtJV2Y/2dsb2JhbABQCYMGT1EGxE2BEBZ0giUBAQEEOjMKEgIBCDYQMhsBBgMCBBMJiDgIBclFF413A1+EOQSZMIE8kTODNIFpQg X-IronPort-AV: E=Sophos;i="4.97,971,1389744000"; d="scan'208";a="321910403" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 02 May 2014 10:02:01 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s42A214D009842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 May 2014 10:02:01 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.202]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 2 May 2014 05:02:01 -0500 From: "Prashanth Patil (praspati)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-patil-tram-turn-serv-disc-01.txt Thread-Index: AQHPZeyd/cHap6Ml70mhGHdWVtbuyJstv0cA Date: Fri, 2 May 2014 10:02:00 +0000 Message-ID: References: <20140502095509.21732.16127.idtracker@ietfa.amsl.com> In-Reply-To: <20140502095509.21732.16127.idtracker@ietfa.amsl.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: [10.65.44.3] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/y8nwRZR6C1pxGe5Jxt_7Aj2RvrA Subject: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-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, 02 May 2014 10:02:11 -0000 A new revision of the TURN server discovery draft has been published. Notable updates : * 300 (Try Alternate) response for anycast. * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients own address to populate the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa) with appropriate NAPTR records pointing to the TURN server. * Learning domain names from own identity. -Prashanth On 5/2/14 3:25 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >has been successfully submitted by Prashanth Patil and posted to the >IETF repository. > >Name: draft-patil-tram-turn-serv-disc >Revision: 01 >Title: TURN Server Auto Discovery >Document date: 2014-05-02 >Group: Individual Submission >Pages: 11 >URL: =20 >http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >Htmlized: =20 >http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 > >Abstract: > Current Traversal Using Relays around NAT (TURN) server discovery > mechanisms are relatively static and limited to explicit > configuration. These are usually under the administrative control of > the application or TURN service provider, and not the enterprise or > the ISP, the network in which the client is located. Enterprises and > ISPs wishing to provide their own TURN servers need auto discovery > mechanisms that a TURN client could use with no or minimal > configuration. This document describes two such mechanisms for TURN > server discovery. > > =20 > =20 > > >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 May 2 06:49: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 240091A6F71; Fri, 2 May 2014 06:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZHKKkTd31Kjd; Fri, 2 May 2014 06:49:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FC11A0816; Fri, 2 May 2014 06:49:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140502134928.14082.52487.idtracker@ietfa.amsl.com> Date: Fri, 02 May 2014 06:49:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/t_h2GhTv-bJYk04pUKDPeK_XUtw Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-dtls-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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, 02 May 2014 13:49:30 -0000 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-02.txt Pages : 15 Date : 2014-05-02 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-dtls-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/ From nobody Fri May 2 06:57:43 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 0868B1A0A01 for ; Fri, 2 May 2014 06:57:40 -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 KZrsS_KwH7vB for ; Fri, 2 May 2014 06:57:38 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB9C1A0816 for ; Fri, 2 May 2014 06:57:38 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id lx4so5062332iec.10 for ; Fri, 02 May 2014 06:57:35 -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=a0kH6y19GY0ES8uWz9Uwh0HfVb4F9cRudH8DkJIL5Ss=; b=hpfKLiAFTSfCR/dWNt+f1hdTg3WLa65yOWzb4LDR4XBiyvRd/BgnTjXLHF3PIF2Ue+ e88ii8G6fLCYt+yBqj+rVqJNbKZMsDsiP21I4A6QuEFqQ23fUhQ7grPKoqQrUBxAk6YW URpW8K1ce9bjxHmYMGWbbX5+4C7IXkD6LIRXI= 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=a0kH6y19GY0ES8uWz9Uwh0HfVb4F9cRudH8DkJIL5Ss=; b=ccg5uWlKBtTez9UhHJchRlEkfApuMpEgVDXpfQJqEHCIc+iAkK1LeMbol2LVqxiDIG cD2H9vMDRosOGeqv8/Rk8RXflueOKL2+6rBqkqH6cU3cTCvxhpYe8dTo7tJXDz4OBPL1 Rok2JE7UdxlhvnrRAMuGrfsuYfKseqge62MMONpDMLoEN8EPH6tFLSVkZBk95zIxlVyZ j4xNdG9ZgBVqXbDnT7eC15tKCTJc35c4Hm1MH7AR8o4ziE0xrmTuUz8esZda5yxNvVXl mOhxCjZqLijL97TSdPBSouijaOBbFlsL0GO7EIfMwgsBURWgY2fqqD9PilgMNLnzOUX9 cQnw== X-Gm-Message-State: ALoCoQljDkaLAgwQknmr+hG8lrLMe+4rBo6v1QO+JCiESbjNZIYIzmlpwhMcyHr+s9nkFhYX5UJk X-Received: by 10.42.99.138 with SMTP id w10mr16714189icn.42.1399039055734; Fri, 02 May 2014 06:57:35 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id s1sm8289693igr.14.2014.05.02.06.57.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 06:57:34 -0700 (PDT) Message-ID: <5363A44D.2060300@getjive.com> Date: Fri, 02 May 2014 07:57:33 -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: tram@ietf.org References: <20140502134928.14082.52487.idtracker@ietfa.amsl.com> In-Reply-To: <20140502134928.14082.52487.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aw50gv7o4eDaceFrqNAP3m5cEAWwg687A" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OYNoSEkf-wya8K0uqBkkh_aQKKk Subject: Re: [tram] I-D Action: draft-ietf-tram-stun-dtls-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, 02 May 2014 13:57:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aw50gv7o4eDaceFrqNAP3m5cEAWwg687A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This new version closes the two remaining open issues: 1. For the question about IP address in STUN/TURN URIs, we used the text that was discussed in the mailing-list. 2. The other open issue was about PFS cipher suite. We went back to the minutes of the rtcweb session in London and added text that mirrors the consensus: http://www.ietf.org/proceedings/89/minutes/minutes-89-rtcweb: "Security / Security Architecture ------- Eric proposes preferring (i.e., SHOULD) PFS cipher suites over non-PFS cipher suites. Asks whether this should be MUST. Belief is that MTI ciphers for WebRTC will include PFS options, so they will offer. Consensus call: * For WebRTC implementations, they MUST offer/select PFS over non-PFS? (large hums) * opposed (none)" With all open issues closed, we believe that this draft is now ready for WGLC. Thanks. On 5/2/14, 7:49 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the TURN Revised and Modernized Working G= roup of the IETF. >=20 > Title : Datagram Transport Layer Security (DTLS) as T= ransport for Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Filename : draft-ietf-tram-stun-dtls-02.txt > Pages : 15 > Date : 2014-05-02 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stun-dtls-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --aw50gv7o4eDaceFrqNAP3m5cEAWwg687A 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/ iQEcBAEBAgAGBQJTY6RNAAoJEMUNRP98lsiXVbcH/jw6LE1pcKouu/1QqWxN+GZP m3sAAUDm3d1ueCymV7CjXs2RzUEo1+VHGQc3KD/sgNxnxled+XFotmaxZXZAuHSq OEtUzCaDwh4S0a13VUIYUWDkA5fh3s+7OWClf45bn3lMvIvGWaWH+1eBsmPaXw3V HcmaNtgEcTuM1wizJi2KzVrTR/xrSoTvyk9DOuh+kEOBU0ffI8Bdc1fJxIlw1+24 Ut40HEdtgXUrjFNNBYsOAQmHX5PPCD8ycUcgVBtJdV8q+4wAT5L9Y2BF4DR0LxkI VZnzmIBpCAnJsiw/3dzkKOFsyLx6usqO+/8GZ9wj1To7AoK3tfwNxUvDuYRliDo= =kU6p -----END PGP SIGNATURE----- --aw50gv7o4eDaceFrqNAP3m5cEAWwg687A-- From nobody Fri May 2 11:44: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 E4CFB1A6FA9 for ; Fri, 2 May 2014 11:43:59 -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 D9mq37ipPVJX for ; Fri, 2 May 2014 11:43:59 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id C30081A0913 for ; Fri, 2 May 2014 11:43:58 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta08.westchester.pa.mail.comcast.net with comcast id x4Qn1n0090cZkys586jwzu; Fri, 02 May 2014 18:43:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id x6jw1n00A3ZTu2S3W6jwfr; Fri, 02 May 2014 18:43:56 +0000 Message-ID: <5363E76C.1050807@alum.mit.edu> Date: Fri, 02 May 2014 14:43:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140502095509.21732.16127.idtracker@ietfa.amsl.com> 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=1399056236; bh=cJdCqnP84k7yJd7jKkpZSRzkQYKCS3Ln1nHrDtIyJq0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dewE6Vk18TX7xEHDrzYFZZKr6eZzqdoJB6DBzX/qavdsGXEWiFnJxihy5Wjwu+sci 7FgpsQcJ4HA5V80Dc+JZP6QG7+q5rdIRWMzoEeTtLkb8LPFnIfj+PM218Z2HNlyTry u9DzK6skiBUhoMGvapTWTF7Cck/3iBfmyJZzD4xjFn4rf/P6H0VGTS5LW8vYIbQJW1 ou0OnNHYKT5niW9ZThOSygPAKxlY+ek34jse6V/aMzu42KUBxzAuu6XgOoElvQw2KJ OpF0AB/EFwRWFCa3brPlcctWc62ir0v82z5CMDHiHiy5kLr04yxKSXO6MkjKMA3Sdp VW89KT3/ovPaA== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wInDyuCp5wAAD56fO_vOf4tm6zw Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-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, 02 May 2014 18:44:00 -0000 There is another possible mechanism for retrieving a domain name for service discovery that isn't mentioned. It is analogous to "From own Identity". I guess I would call it "From target identity". In the case of SIP it would be to use the domain name of the To-URI. This would be useful when a domain wants to make itself be reachable even from clients that have no better way of discovering a TURN server. In general it is probably better to use one of the other techniques when possible, because the result can be used to talk to any target. But this is still a good option when the others fail. And it should be attractive to servers that want to maximize their reachability. (I mentioned this one before, some time ago, but I guess it got lost along the way.) Is there any reason not to include this as 4.1.4? Thanks, Paul On 5/2/14 6:02 AM, Prashanth Patil (praspati) wrote: > A new revision of the TURN server discovery draft has been published. > Notable updates : > > * 300 (Try Alternate) response for anycast. > * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients own > address to populate the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa) > with appropriate NAPTR records pointing to the TURN server. > * Learning domain names from own identity. > > -Prashanth > > > On 5/2/14 3:25 PM, "internet-drafts@ietf.org" > wrote: > >> >> A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >> has been successfully submitted by Prashanth Patil and posted to the >> IETF repository. >> >> Name: draft-patil-tram-turn-serv-disc >> Revision: 01 >> Title: TURN Server Auto Discovery >> Document date: 2014-05-02 >> Group: Individual Submission >> Pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >> Htmlized: >> http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-patil-tram-turn-serv-disc-01 >> >> Abstract: >> Current Traversal Using Relays around NAT (TURN) server discovery >> mechanisms are relatively static and limited to explicit >> configuration. These are usually under the administrative control of >> the application or TURN service provider, and not the enterprise or >> the ISP, the network in which the client is located. Enterprises and >> ISPs wishing to provide their own TURN servers need auto discovery >> mechanisms that a TURN client could use with no or minimal >> configuration. This document describes two such mechanisms for TURN >> server discovery. >> >> >> >> >> >> 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 > From nobody Sat May 3 23:44:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA0A1A0165 for ; Sat, 3 May 2014 23:44:27 -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 UHbNik9gdTYY for ; Sat, 3 May 2014 23:44:26 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id C89141A015D for ; Sat, 3 May 2014 23:44:25 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm4so4164576wib.5 for ; Sat, 03 May 2014 23:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vzVez5+3PM8YCy97hNhk9KPF51Z8cO0aWEx2I243kLE=; b=eQ/X8pbvR9uL8k+dFCdoZQJJO3dCy3fPoq0LEBIhNq3EZHHCzxrUtpeO/KGVqQsJwe brFEtef1+mZxaGWaT5XRpvcrRBS9WZEq43qStHRKewbe63+bTts+3LF+faiEbL1NWkvt cy2xB60OoDvz/HXDU8O/ecAVerHdRIZkZFcJtOVAmQOJ0BuLplQx64bHLpjwBVNO0Bu8 vElaq3Ay3toWaVQwVyHqAP9A6bE8qSIHGZ7O2kosAi17eTZuAZWuEZRvJnNyH+PHEYIN +HEOJ1ZPmXrllY98wfwYoTelv/SUVe4gTn9MZiMGssZadqB+iEZhzXBPp2Ed/bS8q3pY k9Cw== MIME-Version: 1.0 X-Received: by 10.180.14.229 with SMTP id s5mr10558872wic.10.1399185862343; Sat, 03 May 2014 23:44:22 -0700 (PDT) Received: by 10.194.9.67 with HTTP; Sat, 3 May 2014 23:44:22 -0700 (PDT) Date: Sat, 3 May 2014 23:44:22 -0700 Message-ID: From: Oleg Moskalenko To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=f46d040fa0064cc13404f88d58a6 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BfNaao91CLiIq5w6AAs7jkIw5_c Subject: [tram] draft-johnston-tram-stun-origin-02.txt pilot implementation 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, 04 May 2014 06:44:27 -0000 --f46d040fa0064cc13404f88d58a6 Content-Type: text/plain; charset=UTF-8 I was trying to provide a sort of reference implementation and proof of concept for the multi-tenant TURN server. I created a clone (a spin-off) of rfc5766-turn-server project and I was working on the multiple realms support as I understand that concept: https://code.google.com/p/coturn/ This implementation is backward-compatible with rfc5766-turn-server project but the code is more complex and it uses a different (also more complex) database structure. My intention is to put all new TRAM features into that new project. Oleg --f46d040fa0064cc13404f88d58a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was trying to provide a sort of reference implementation= and proof of concept for the multi-tenant TURN server. I created a clone (= a spin-off) of rfc5766-turn-server project and I was working on the multipl= e realms support as I understand that concept:


This implementation is= backward-compatible with rfc5766-turn-server project but the code is more = complex and it uses a different (also more complex) database structure.

My intention is to put all new TRAM features into that = new project.

Oleg

--f46d040fa0064cc13404f88d58a6-- From nobody Sun May 4 23:50:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925D21A0261 for ; Sun, 4 May 2014 23:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qMrxV5YD22q2 for ; Sun, 4 May 2014 23:50:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B68751A0101 for ; Sun, 4 May 2014 23:50:22 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-d8-536734aa4d06 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D2.C6.05409.AA437635; Mon, 5 May 2014 08:50:18 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.174.1; Mon, 5 May 2014 08:50:18 +0200 Message-ID: <536734AA.2050006@ericsson.com> Date: Mon, 5 May 2014 08:50:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3RneVSXqwwZzF5hYf1l5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoVr71kLrnJWbPv0jr2B8TN7FyMnh4SAicT0WeugbDGJC/fW s3UxcnEICRxllHh0ZzqUs4xRYvKPyUwgVbwC2hLfp/xmBLFZBFQkbqz9ywZiswlYSNz80Qhm iwoES2x4+Jcdol5Q4uTMJywgtoiAsMTcg3fBbGEBZ4kNj7cCzeEA2iwu0dMYBBJmFtCTmHK1 hRHClpdo3jqbGcQWAlrb0NTBOoGRfxaSqbOQtMxC0rKAkXkVo2hxanFSbrqRsV5qUWZycXF+ nl5easkmRmCoHdzyW3UH4+U3jocYBTgYlXh4i79EBguxJpYVV+YeYpTmYFES5/1yyydYSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6NrgMWr3Vummz89yVxiftxC8O9Cn//H+O2M7vY+exGf VL7n80ne283pp5Nfaqd9zkgV+JkxJX/nJB5Pp/85n1eUcM/2W+59vLdhtx3fW2Ovn6cLDnWJ aks32k67d6aT71eatF7pcrlfSus2ROgwKEzPM41P9j8pKlrdyHyo6dZE9SmrD7uZ/1ZiKc5I NNRiLipOBAAWWFg/FgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/1_UVj9fakISVg_DwUvITHGbtZDI Subject: [tram] Request to update STUN's IANA registration in STUNbis work 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, 05 May 2014 06:50:24 -0000 WG, The AVTCORE WG have had a discussion regarding DTLS-SRTP (RFC 5764) and STUN's IANA registrations. To ensure that the IANA rules are accurate and reflect the reality of the environment STUN is operating in today, there appear to be a desire to request that STUN's IANA rules are changed. With the approval of RFC 5764 it was created a value overlap in the use cases where DTLS-SRTP and STUN are co-existing on the same transport flow. This value overlap exists for any method value outside the range 0-127 for each class of STUN methods. Thus to avoid any collisions in future registrations it appears prudent to restrict method registrations to this range to avoid collisions in the cases where one uses STUN and DTLS-SRTP. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue May 6 00:08: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 65F531A00BA for ; Tue, 6 May 2014 00:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 nXTtCrSFZUNC for ; Tue, 6 May 2014 00:08:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 737261A0154 for ; Tue, 6 May 2014 00:08:02 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-a7-53688a4dd267 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.48.05409.D4A88635; Tue, 6 May 2014 09:07:58 +0200 (CEST) Received: from [147.214.153.78] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.174.1; Tue, 6 May 2014 09:07:57 +0200 Message-ID: <53688A4D.8050208@ericsson.com> Date: Tue, 6 May 2014 09:07:57 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3RtevKyPY4OJEHosPay+wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9vMG+wF3xgrFuz2bmA8ytjFyMkhIWAicbtnGRuELSZx4d56 IJuLQ0jgKKPE5HWT2SGc1YwSjf83s4JU8QpoS7Se+8kEYrMIqEgsvHwbrJtNwEJiy637LCC2 qECUxK6+X+wQ9YISJ2c+AYuLCAhLzD14F8wWBppzeOs+IJsDaLO4RE9jEEiYWUBPYsrVFkYI W15i+9s5zCC2EFD58mctLBMY+WchmToLScssJC0LGJlXMYoWpxYn5aYbGeulFmUmFxfn5+nl pZZsYgQG2sEtv1V3MF5+43iIUYCDUYmHd3drRrAQa2JZcWXuIUZpDhYlcd4vt3yChQTSE0tS s1NTC1KL4otKc1KLDzEycXBKNTD6npft7VKz2L7n4xxBvQunNk05pFtkbPqac9LEya4bLBcE ro5iKf6zvCsm7rfd+XV+IkztB5j29u5mtitPdHWr+/aT5+SWqWv6rzDf7pA63Xp5X1JOSI/S tRqfzTudJr072XHuYZOUz4mok8lCtd+eNa9YIvGHLaDOkLfIjSfn+Zbb5pXlLYFKLMUZiYZa zEXFiQBk4iHFFQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/kA4HbqcfK_scgOwMvGZe8R0LWf8 Subject: [tram] WGLC: draft-ietf-tram-stun-dtls-02 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, 06 May 2014 07:08:05 -0000 Folks, we are starting a Working Group Last Call (WGLC) on the following draft: http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ This WGLC will end on May 21st. Please, send your comments to this list. Thanks, Gonzalo From nobody Tue May 6 03:55: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 1837E1A07A4 for ; Tue, 6 May 2014 03:55:30 -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 8AlBjMTvJ5S1 for ; Tue, 6 May 2014 03:55:28 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B91A02A5 for ; Tue, 6 May 2014 03:55:28 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id as1so9643745iec.3 for ; Tue, 06 May 2014 03:55:24 -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; bh=asEyomg8Mg5l3pabKBKLBxX+GQaPxkxPwyWhlMslGXM=; b=H8VMcbMsdKrcTIRePpnHFHe2IoV57Q+esHjt6tvXnOrtkF9Ep9VLvsGzyoYMhLH4cO Ba6q/vszBDsDAKQi034FOKz796twmfPkJ/CeeylQ1r6y9S6pFUbHjOXBbbbm4jTsNEpt G6/tcIcP0kW+XqstJRQEi6gmPRAdXr8UllIGM= 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; bh=asEyomg8Mg5l3pabKBKLBxX+GQaPxkxPwyWhlMslGXM=; b=GLOMQuH33YXBGHa2HPCJKueR2HtKd3cGJIO0mnvbgew0kyINwgbC4oUhEpFL/Hjfhl 86vSvZCBqidHawgqLMbO64o4msMoqFUJXPc1O7RoR/adJaYZxbyVnQJ57TXhQnAhxmDC BMxyaw4i0R3J15gHOPwhJ6/Ka9+T90Aj+dM+kAbNAfF6MsdegCclO1JmB4idF2eeKe9F FzvfIvZ5DalydrQNLdiiMkzHt+w/8c3Psiln0IaoBeUZiMAPPcKE8KbR7NVsD0WxVjI6 +1IKu4/m6RqL7ppCWDB4xFH6MZCYDz3Z9KCLbTHMvd4XmRKaepdTt8pXOpD7ns4MtY/P jDnQ== X-Gm-Message-State: ALoCoQk4hqk5Qqw2XzZdwPvGPPT/Gzp6DSSj1b5XVAgp/36oez9ngXuH/pIpxmrg0fMikdu+1yID X-Received: by 10.50.49.109 with SMTP id t13mr31350698ign.2.1399373724532; Tue, 06 May 2014 03:55:24 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id k8sm37872835ige.0.2014.05.06.03.55.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 03:55:18 -0700 (PDT) Message-ID: <5368BF90.2070307@getjive.com> Date: Tue, 06 May 2014 04:55:12 -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: "tram@ietf.org" X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3x4B0nkIeWurlsE5JFSn4SwvnpJT6O5VX" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XcRuG4DqoqclB8FB91EwOQRg2S0 Subject: [tram] Review of draft-johnston-tram-stun-origin-02 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, 06 May 2014 10:55:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3x4B0nkIeWurlsE5JFSn4SwvnpJT6O5VX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A1. Intended Status: Informational Shouldn't this be Standard Track? A2. Section 1, 2nd paragraph, last sentence: "as generating the response.= =2E." I do not think that the reason for no authentication for the NAT Discovery Usage is because it is less work, but because there is no resource to protect so adding more work does not make sense. A3. Section 1, 8th paragraph I do not think that the ORIGIN should be used to select the certificate when (D)TLS is used. First it does not work with DANE, as when an SRV (and probably NAPTR too, but that's undefined yet) RR redirects to a different domain, the domain to be checked with is the host name, not the service domain (see draft-ietf-dane-srv). For non-DANE cases, I think that the correct way to select the certificate is to use SNI. So I would suggest to restrict the normative use of ORIGIN only to select realms. A4. Section 2.2. ORIGIN attribute usage The text does not say if the ORIGIN attribute should/can be provided after the authentication (i.e. refresh, data packets, etc...) A5. Section 2.2. Mandatory support for server How a TURN server that requires the usage of ORIGIN can signal this? A6. Section 2. Other Usages I think that other STUN Usages should be listed after section 2.3: - Media Keep-Alive Usage (Section 20 of RFC5245) - SIP Keep-Alive Usage (RFC 5626) - NAT Behavior Discovery Usage (RFC 5780) A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute is present, the contents of the ORIGIN attribute are integrity protected.= " Which never happen in the usages listed in the document: for section 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is needed to select the realm, so the ORIGIN is sent before it can be protected. Perhaps 2.2 should say that if ORIGIN was sent to select the realm, it MUST be repeated at identical on the second Allocate (the one that has an M-I) and that the server MUST reject it if it is not identical to the first one. Not sure it matters though. Nits ---- - Section 2, 2nd paragraph: "The number used for the this in the ..." Does not parse. --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --3x4B0nkIeWurlsE5JFSn4SwvnpJT6O5VX 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/ iQEcBAEBAgAGBQJTaL+VAAoJEMUNRP98lsiXZsYIAJAhrXM8/CKosl3irvMCZB9L REipzOt28jC465+UL/jJDJ2/3fUKN0hhrxUZHpTOompcxE1gMC/HF6TAhweBWm3d +D1H5rN8vjThLYnJKcf1+7Szjb936sNda6/YZnSi0fSosQET5f/7kkpTUrIMGQVe QR9WpgkZ2lWEbe67HVJmlb3xGc9et5JZPNvdsFPpHmQasJ6u+KfVOV2JVOhnq7/s DcKJVLXzo7T3W7r6J07H1W9uoYbxb1M2tVXNsuE7lEnTQe9xN7zZXD65LL7kZ3aE yVkoYjpLPGwwOJj2jcZwQYk+vy2KFjfRiNXKaD40WJw4gS5rTBEEFdmevHl9IpE= =V7K0 -----END PGP SIGNATURE----- --3x4B0nkIeWurlsE5JFSn4SwvnpJT6O5VX-- From nobody Tue May 6 06:55:54 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 66F721A0341 for ; Tue, 6 May 2014 06:55:53 -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 2AWzTujHizNJ for ; Tue, 6 May 2014 06:55:51 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8241A1A065C for ; Tue, 6 May 2014 06:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3719; q=dns/txt; s=iport; t=1399384548; x=1400594148; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jvqoVPZfgf4FwPWcR5nuQAeLxZPh02fHzHDHIWJNLTI=; b=JlZULzyBzGViBGW0OQuyn4UxRFd95UcYhdAAvp+9HUvN8bIjWeWpPCjT pMp11D42ybgERJKi05VTQR89ZsHfFJR4LTpDoK9b/Y67rwnt8CMG9S7pu ylGmoxHhpWOStCaI9h3AYOyLopUOIHIy46GUL7ntTlBA5xisPasrsh4Cm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcOAJrpaFOtJA2G/2dsb2JhbABQCQ6CeE9RB6pFAQEBAQEBBQGSUoc5gR4WdIIlAQEBAwEBAQE3MwEJEgIBCA4KHhAnCxwJAgQBEgmIMAgIBc1wF4VWg1uERgNfhD8EmTeBPJE/gXV/QG2BAEI X-IronPort-AV: E=Sophos;i="4.97,997,1389744000"; d="scan'208";a="322721109" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 06 May 2014 13:55:47 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s46DtlBE008808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 13:55:47 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.202]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 6 May 2014 08:55:47 -0500 From: "Prashanth Patil (praspati)" To: Paul Kyzivat , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-01.txt Thread-Index: AQHPZeyd/cHap6Ml70mhGHdWVtbuyA== Date: Tue, 6 May 2014 13:55:45 +0000 Message-ID: References: <20140502095509.21732.16127.idtracker@ietfa.amsl.com> <5363E76C.1050807@alum.mit.edu> In-Reply-To: <5363E76C.1050807@alum.mit.edu> 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: [72.163.172.197] Content-Type: text/plain; charset="us-ascii" Content-ID: <45D7E43FD16D974CB2B13A889E6E28C1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/d_j9uG1IfowciolbQuNqeVPQDps Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-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, 06 May 2014 13:55:53 -0000 On 5/3/14 12:13 AM, "Paul Kyzivat" wrote: >There is another possible mechanism for retrieving a domain name for >service discovery that isn't mentioned. It is analogous to "From own >Identity". I guess I would call it "From target identity". In the case >of SIP it would be to use the domain name of the To-URI. > >This would be useful when a domain wants to make itself be reachable >even from clients that have no better way of discovering a TURN server. > >In general it is probably better to use one of the other techniques when >possible, because the result can be used to talk to any target. But this >is still a good option when the others fail. And it should be attractive >to servers that want to maximize their reachability. > >(I mentioned this one before, some time ago, but I guess it got lost >along the way.) > >Is there any reason not to include this as 4.1.4? The intent was to provide best possible means to discover TURN offered by your domain/network, 'from target identity' was hence not included. Not necessarily within the scope of server discovery, but on what basis would the TURN server from target domain allow requests from unknown users? -Prashanth > > Thanks, > Paul > >On 5/2/14 6:02 AM, Prashanth Patil (praspati) wrote: >> A new revision of the TURN server discovery draft has been published. >> Notable updates : >> >> * 300 (Try Alternate) response for anycast. >> * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients >>own >> address to populate the DNS reverse zone (i.e., in-addr.arpa or >>ip6.arpa) >> with appropriate NAPTR records pointing to the TURN server. >> * Learning domain names from own identity. >> >> -Prashanth >> >> >> On 5/2/14 3:25 PM, "internet-drafts@ietf.org" >> wrote: >> >>> >>> A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >>> has been successfully submitted by Prashanth Patil and posted to the >>> IETF repository. >>> >>> Name: draft-patil-tram-turn-serv-disc >>> Revision: 01 >>> Title: TURN Server Auto Discovery >>> Document date: 2014-05-02 >>> Group: Individual Submission >>> Pages: 11 >>> URL: >>>=20 >>>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01.t >>>xt >>> Status: >>> https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 >>> >>> Abstract: >>> Current Traversal Using Relays around NAT (TURN) server discovery >>> mechanisms are relatively static and limited to explicit >>> configuration. These are usually under the administrative control >>>of >>> the application or TURN service provider, and not the enterprise or >>> the ISP, the network in which the client is located. Enterprises >>>and >>> ISPs wishing to provide their own TURN servers need auto discovery >>> mechanisms that a TURN client could use with no or minimal >>> configuration. This document describes two such mechanisms for TURN >>> server discovery. >>> >>> >>> >>> >>> >>> 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 >> > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Tue May 6 09:59: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 7EFCD1A0175 for ; Tue, 6 May 2014 09:59:54 -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 ernp4X2tT1Yn for ; Tue, 6 May 2014 09:59:53 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A99921A01AE for ; Tue, 6 May 2014 09:59:52 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so5672511wgh.28 for ; Tue, 06 May 2014 09:59:48 -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=CvC6IUta/+waUVri8x+Lx95f4wiz1TmKYscmT8xlxlg=; b=J3V1lHsFJnT3Ii+Y7rpkTkGKKX+T8QySKcFidZUgoYWc5BLtXnaF36NJzSvXZRzW6t UD+g34qBw/as/hq1Zjmx4bTh30Exj8LEbzNrc/IoE9EiOuM4fXaE/9pY2CBrDlKteBBy jnkUhS9vzX4nZblFLXR3v7dnlT35Js+/ta6IIumF0KrVDm5LuMXpLcROEtAsYFDM/P5w OSlmFSWEM79MVUdSFp2te8bF7XCOoLUNg3sZ9OFl8Nu5BunOTIi7qsWG8ZYuWR95RiVL Rbqzop0ulM1WExhrdgraUET63qBdJKXTVdVCAd07jZYDOp1m4orxdEOCTcmHGEShPq0i TgfA== MIME-Version: 1.0 X-Received: by 10.180.187.225 with SMTP id fv1mr22095935wic.14.1399395588447; Tue, 06 May 2014 09:59:48 -0700 (PDT) Received: by 10.194.9.67 with HTTP; Tue, 6 May 2014 09:59:48 -0700 (PDT) In-Reply-To: <5368BF90.2070307@getjive.com> References: <5368BF90.2070307@getjive.com> Date: Tue, 6 May 2014 09:59:48 -0700 Message-ID: From: Oleg Moskalenko To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=001a11c25d30f3262b04f8be2c84 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/jP2XiS_oI1-cMxk1OXOUId4GoeQ Cc: "tram@ietf.org" Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 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, 06 May 2014 16:59:54 -0000 --001a11c25d30f3262b04f8be2c84 Content-Type: text/plain; charset=UTF-8 please see inline: On Tue, May 6, 2014 at 3:55 AM, Marc Petit-Huguenin wrote: > > > A3. Section 1, 8th paragraph > > I do not think that the ORIGIN should be used to select the certificate > when (D)TLS is used. First it does not work with DANE, as when an SRV > (and probably NAPTR too, but that's undefined yet) RR redirects to a > different domain, the domain to be checked with is the host name, not > the service domain (see draft-ietf-dane-srv). For non-DANE cases, I > think that the correct way to select the certificate is to use SNI. > > So I would suggest to restrict the normative use of ORIGIN only to > select realms. > [Oleg] Technically, you cannot use the ORIGIN for the certificate selection because the (D)TLS negotiation is happening before any TURN ALLOCATE packet is delivered to the server. Although, I am not sure that I see a use case for multiple different TLS certificates on the same network service endpoint, even if it serves multiple realms. > > A4. Section 2.2. ORIGIN attribute usage > > The text does not say if the ORIGIN attribute should/can be provided > after the authentication (i.e. refresh, data packets, etc...) > [Oleg] After the initial negotiation, the ORIGIN is optional and can be used only for logging purposes. > > A5. Section 2.2. Mandatory support for server > > How a TURN server that requires the usage of ORIGIN can signal this? > [Oleg] I suppose that the server just uses a default realm if the ORIGIN is absent. If server requires the ORIGIN, then the default realm can be a bogus realm that has no real users. I do not see a reason to introduce a new error code here. If the client supports ORIGIN then it just always includes ORIGIN (as a comprehensive-optional attribute) into the ALLOCATE request. If the client does not support ORIGIN, then it works with the default realm. I see no valid reasons why a client that supports ORIGIN would want to try ALLOCATE without the ORIGIN. > > A6. Section 2. Other Usages > > I think that other STUN Usages should be listed after section 2.3: > > - Media Keep-Alive Usage (Section 20 of RFC5245) > - SIP Keep-Alive Usage (RFC 5626) > - NAT Behavior Discovery Usage (RFC 5780) > > A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute > is present, the contents of the ORIGIN attribute are integrity protected." > > Which never happen in the usages listed in the document: for section > 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is > needed to select the realm, so the ORIGIN is sent before it can be > protected. Perhaps 2.2 should say that if ORIGIN was sent to select the > realm, it MUST be repeated at identical on the second Allocate (the one > that has an M-I) and that the server MUST reject it if it is not > identical to the first one. Not sure it matters though. > [Oleg] That's right, I think that the wording about the MESSAGE-INTEGRITY must be clarified and/or removed. In the initial ALLOCATE request, the ORIGIN is not protected. In other requests, the ORIGIN is optional and not required - but if it is included, then it will be protected (as virtually any other attribute) but the value of the ORIGIN attribute in those protected messages really does not matter. I do not see any valid attack that can be prevented by checking the ORIGIN attribute value and by protection. It can help only in finding the errors in the software implementation but that is definitely not a valid purpose of the network protocol. Thanks Oleg --001a11c25d30f3262b04f8be2c84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
please see inline:


On Tue, May 6, 2014 at 3:55 AM, Marc Petit-Huguenin <= span dir=3D"ltr"><marcph@getjive.com> wrote:


A3. Section 1, 8th paragraph

I do not think that the ORIGIN should be used to select the certificate
when (D)TLS is used. =C2=A0First it does not work with DANE, as when an SRV=
(and probably NAPTR too, but that's undefined yet) RR redirects to a different domain, the domain to be checked with is the host name, not
the service domain (see draft-ietf-dane-srv). =C2=A0For non-DANE cases, I think that the correct way to select the certificate is to use SNI.

So I would suggest to restrict the normative use of ORIGIN only to
select realms.

[Oleg] Technically, you = cannot use the ORIGIN for the certificate selection because the (D)TLS nego= tiation is happening before any TURN ALLOCATE packet is delivered to the se= rver. Although, I am not sure that I see a use case for multiple different = TLS certificates on the same network service endpoint, even if it serves mu= ltiple realms.
=C2=A0

A4. Section 2.2. ORIGIN attribute usage

The text does not say if the ORIGIN attribute should/can be provided
after the authentication (i.e. refresh, data packets, etc...)


[Oleg] After the initial negotiation,= the ORIGIN is optional and can be used only for logging purposes.
=C2=A0

A5. Section 2.2. =C2=A0Mandatory support for server

How a TURN server that requires the usage of ORIGIN can signal this?

[Oleg] I suppose that the server just uses a = default realm if the ORIGIN is absent. If server requires the ORIGIN, then = the default realm can be a bogus realm that has no real users. I do not see= a reason to introduce a new error code here. If the client supports ORIGIN= then it just always includes ORIGIN (as a comprehensive-optional attribute= ) into the ALLOCATE request. If the client does not support ORIGIN, then it= works with the default realm. I see no valid reasons why a client that sup= ports ORIGIN would want to try ALLOCATE without the ORIGIN.
=C2=A0

A6. Section 2. Other Usages

I think that other STUN Usages should be listed after section 2.3:

- Media Keep-Alive Usage (Section 20 of RFC5245)
- SIP Keep-Alive Usage (RFC 5626)
- NAT Behavior Discovery Usage (RFC 5780)

A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute=
is present, the contents of the ORIGIN attribute are integrity protected.&q= uot;

Which never happen in the usages listed in the document: =C2=A0for section<= br> 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is
needed to select the realm, so the ORIGIN is sent before it can be
protected. =C2=A0Perhaps 2.2 should say that if ORIGIN was sent to select t= he
realm, it MUST be repeated at identical on the second Allocate (the one
that has an M-I) and that the server MUST reject it if it is not
identical to the first one. =C2=A0Not sure it matters though.

[Oleg] That's right, I think that the wording ab= out the MESSAGE-INTEGRITY must be clarified and/or removed. In the initial = ALLOCATE request, the ORIGIN is not protected. In other requests, the ORIGI= N is optional and not required - but if it is included, then it will be pro= tected (as virtually any other attribute) but the value of the ORIGIN attri= bute in those protected messages really does not matter. I do not see any v= alid attack that can be prevented by checking the ORIGIN attribute value an= d by protection. It can help only in finding the errors in the software imp= lementation but that is definitely not a valid purpose of the network proto= col.
=C2=A0
Thanks
Oleg

--001a11c25d30f3262b04f8be2c84-- From nobody Tue May 6 11:03: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 A0DFA1A02F1 for ; Tue, 6 May 2014 11:03:01 -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 XL5TzNP8x9BS for ; Tue, 6 May 2014 11:03:00 -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 15A621A0289 for ; Tue, 6 May 2014 11:02:59 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta12.westchester.pa.mail.comcast.net with comcast id yhV81n00227AodY5Ci2wVg; Tue, 06 May 2014 18:02:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id yi2u1n00A3ZTu2S3fi2vvp; Tue, 06 May 2014 18:02:56 +0000 Message-ID: <536923CB.2080704@alum.mit.edu> Date: Tue, 06 May 2014 14:02:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140502095509.21732.16127.idtracker@ietfa.amsl.com> <5363E76C.1050807@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=1399399376; bh=Q1kATzFr5iFZm7Kol8gzwK8waPtEr3340EZ63apXHzY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HaKGLq/qEU2Ds1bxJvByfkPBEqpNfUHLkJVmjGuCrM+LsDETTo9Y9Q7PK64EJi075 oWapECHNE3LGXnV/ETnYVrWmj0MbwtB9DUF9mmPoBwiLXmGZqBDuBIN5uisPP/n6i5 o2lQi+2m4lXWS3+SdHKQPeHsHoIeFjGnC+6T2mQa14whjEZi2Sutyu4kfMnmH0JJUR RuREknDm6asYPemFNp97TvSXZrSeKmydZAF6EkKsFm8KoCXHuk8nzj8OiMxq1Nhj3H Jk707iCxMU4DckG17Q/1a2dDXjBry5pI8JavEV8pNnoQsgyEyfex/J0Uz0qBpitKc1 C0gAdm6IKqEwg== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/HzgCe8hRwOKXYl4KmAl201MGqVw Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-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, 06 May 2014 18:03:01 -0000 On 5/6/14 9:55 AM, Prashanth Patil (praspati) wrote: > > > On 5/3/14 12:13 AM, "Paul Kyzivat" wrote: > >> There is another possible mechanism for retrieving a domain name for >> service discovery that isn't mentioned. It is analogous to "From own >> Identity". I guess I would call it "From target identity". In the case >> of SIP it would be to use the domain name of the To-URI. >> >> This would be useful when a domain wants to make itself be reachable >> even from clients that have no better way of discovering a TURN server. >> >> In general it is probably better to use one of the other techniques when >> possible, because the result can be used to talk to any target. But this >> is still a good option when the others fail. And it should be attractive >> to servers that want to maximize their reachability. >> >> (I mentioned this one before, some time ago, but I guess it got lost >> along the way.) >> >> Is there any reason not to include this as 4.1.4? > > The intent was to provide best possible means to discover TURN offered by > your domain/network, 'from target identity' was hence not included. I didn't see anything in the description of service discovery that limited it that way. > Not necessarily within the scope of server discovery, but on what basis > would the TURN server from target domain allow requests from unknown users? What I had in mind was that this service could be provided by the target domain for the benefit of those attempting to reach it. The goal being to maximize its reachability, even from clients that cannot discover a turn service at the source end. I guess what you are suggesting is that somebody might abuse this, discovering this TURN server and then using it to contact some unrelated party. I haven't thought about it a lot, but perhaps it could arrange to only work when the other end is within the domain it supports. Thanks, Paul > -Prashanth > > >> >> Thanks, >> Paul >> >> On 5/2/14 6:02 AM, Prashanth Patil (praspati) wrote: >>> A new revision of the TURN server discovery draft has been published. >>> Notable updates : >>> >>> * 300 (Try Alternate) response for anycast. >>> * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients >>> own >>> address to populate the DNS reverse zone (i.e., in-addr.arpa or >>> ip6.arpa) >>> with appropriate NAPTR records pointing to the TURN server. >>> * Learning domain names from own identity. >>> >>> -Prashanth >>> >>> >>> On 5/2/14 3:25 PM, "internet-drafts@ietf.org" >>> wrote: >>> >>>> >>>> A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >>>> has been successfully submitted by Prashanth Patil and posted to the >>>> IETF repository. >>>> >>>> Name: draft-patil-tram-turn-serv-disc >>>> Revision: 01 >>>> Title: TURN Server Auto Discovery >>>> Document date: 2014-05-02 >>>> Group: Individual Submission >>>> Pages: 11 >>>> URL: >>>> >>>> http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01.t >>>> xt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-patil-tram-turn-serv-disc-01 >>>> >>>> Abstract: >>>> Current Traversal Using Relays around NAT (TURN) server discovery >>>> mechanisms are relatively static and limited to explicit >>>> configuration. These are usually under the administrative control >>>> of >>>> the application or TURN service provider, and not the enterprise or >>>> the ISP, the network in which the client is located. Enterprises >>>> and >>>> ISPs wishing to provide their own TURN servers need auto discovery >>>> mechanisms that a TURN client could use with no or minimal >>>> configuration. This document describes two such mechanisms for TURN >>>> server discovery. >>>> >>>> >>>> >>>> >>>> >>>> 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 >>> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > > From nobody Tue May 6 15:13: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 54F821A0535 for ; Tue, 6 May 2014 15:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 nwZP1aVcdSKj for ; Tue, 6 May 2014 15:13:18 -0700 (PDT) Received: from nomis80.org (nomis80.org [23.92.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0451A049F for ; Tue, 6 May 2014 15:13:18 -0700 (PDT) Received: from porto.nomis80.org (unknown [66.7.113.101]) by nomis80.org (Postfix) with ESMTPSA id 2240010EAE for ; Tue, 6 May 2014 22:13:49 +0000 (UTC) Message-ID: <53695E79.4040202@per.reau.lt> Date: Tue, 06 May 2014 18:13:13 -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: <20140502095509.21732.16127.idtracker@ietfa.amsl.com> <5363E76C.1050807@alum.mit.edu> <536923CB.2080704@alum.mit.edu> In-Reply-To: <536923CB.2080704@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-RfK3CucYzLbiae4rxLML0I6ECA Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-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, 06 May 2014 22:13:20 -0000 Le 2014-05-06 14:02, Paul Kyzivat a écrit : >> Not necessarily within the scope of server discovery, but on what basis >> would the TURN server from target domain allow requests from unknown >> users? > > What I had in mind was that this service could be provided by the target > domain for the benefit of those attempting to reach it. The goal being > to maximize its reachability, even from clients that cannot discover a > turn service at the source end. > > I guess what you are suggesting is that somebody might abuse this, > discovering this TURN server and then using it to contact some unrelated > party. > > I haven't thought about it a lot, but perhaps it could arrange to only > work when the other end is within the domain it supports. The problem is the server doesn't know who the other end is when it receives an allocate request... Simon From nobody Wed May 7 02:56:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD7E1A0424 for ; Wed, 7 May 2014 02:56:05 -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 9h5wl2qu3hsK for ; Wed, 7 May 2014 02:56:03 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 473041A03D1 for ; Wed, 7 May 2014 02:56:03 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so872133igd.2 for ; Wed, 07 May 2014 02:55:59 -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=tz1fRqRXI2a6qptYL+Iaayc7BVG4o9Y/gKWuRbO3LMA=; b=APECtpVGutGzLnw6Ib+ZK6A0yFk+3bmIwyVh9bojketZ4Yf6PXt1nuiuC8qzLFLJC7 kzkwVwyfrxnfwe/0PyjngXBvo74JhAp1N1X0fyQiK+rr+spmoo1di8kPPtdVcMm9i3K2 2PIBpxoSmNijec+Z7GbkVM0pa5o0690InX+3A= 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=tz1fRqRXI2a6qptYL+Iaayc7BVG4o9Y/gKWuRbO3LMA=; b=aT023aextR6SXUTAqj/tRJyncMjZ7MWkb3KEiC6qOpNQdVxWNRscXcJhr0k//xmUrR KBS1ewNjRrghBfEbVZ6ArrUaYGBYQsDjzFiN4M12glQOtGYPDYxchadgGxm9sqM61r8Z CSNpVcirpl+l1QqL//BLi+7htbxJJAS2MYB4oyYHzgxxNstsF190Dj9LQWsyqVZH61zT nrg14UcysPLQWOi6fHJBfwMMUJ0c1da4ftqyyA2Jmusk5GoPOHUNNucD3825RJMwp0w8 KhNtx1HV0/e6NHg027NW9H+oCqzTOzswbepgYr41YyWEHYVazDu2CtGzPGAmOfqDV7DI Q+bg== X-Gm-Message-State: ALoCoQlSDQgTrUQz643108rnd4NjCkuZ4w7daTUgUqEzHKrfIL02ZCOuu9nuXOWFAOMvK8ejW0Gw X-Received: by 10.50.25.136 with SMTP id c8mr41388749igg.26.1399456559071; Wed, 07 May 2014 02:55:59 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id x7sm16589093igw.1.2014.05.07.02.55.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 02:55:57 -0700 (PDT) Message-ID: <536A0326.7040704@getjive.com> Date: Wed, 07 May 2014 03:55:50 -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: Magnus Westerlund , tram@ietf.org References: <536734AA.2050006@ericsson.com> In-Reply-To: <536734AA.2050006@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OalA7Xn7rObmh646LiXSV0ow4a7DCVcxH" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/225yv9W2-MNnvo6DVxr9jCYpW04 Subject: Re: [tram] Request to update STUN's IANA registration in STUNbis work 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, 07 May 2014 09:56:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OalA7Xn7rObmh646LiXSV0ow4a7DCVcxH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Magnus, On 5/5/14, 12:50 AM, Magnus Westerlund wrote: > WG, >=20 > The AVTCORE WG have had a discussion regarding DTLS-SRTP (RFC 5764) and= > STUN's IANA registrations. To ensure that the IANA rules are accurate > and reflect the reality of the environment STUN is operating in today, > there appear to be a desire to request that STUN's IANA rules are chang= ed. >=20 > With the approval of RFC 5764 it was created a value overlap in the use= > cases where DTLS-SRTP and STUN are co-existing on the same transport > flow. This value overlap exists for any method value outside the range > 0-127 for each class of STUN methods. Thus to avoid any collisions in > future registrations it appears prudent to restrict method registration= s > to this range to avoid collisions in the cases where one uses STUN and > DTLS-SRTP. >=20 I do not think this is the right thing to do. The problem is that what RFC 5764 did was allocating most of the IETF Review STUN Method codepoints without IETF review and all of the Designated Expert STUN Method codepoints without expert review, this last point being the main problem in my opinion, as now nobody can request one of those. So I have two proposals, first to fix the problem itself: 1. An additional problem with RFC 5764 is that not only it requisitioned most of the STUN methods codepoints, but it did it unnecessarily. Instead of this: +----------------+ | 127 < B < 192 -+--> forward to RTP | | packet --> | 19 < B < 64 -+--> forward to DTLS | | | B < 2 -+--> forward to STUN +----------------+ It should have said this: +----------------+ | 127 < B < 192 -+--> forward to RTP | | packet --> | 19 < B < 64 -+--> forward to DTLS | | | B < 20 -+--> forward to STUN +----------------+ That would have left 1280 codepoints instead of a mere 128. So my proposal is that AVTCORE write a standard track RFC updating RFC 5764 with the modification above, and with a request to modify the IANA registry so that the new RFC Review range is 0x000-0x2FF and the new Designated Expert range is 0x300-0x4FF. 2. This problem is basically a failure in having RFC 5764 reviewed by NAT traversal experts before its publication. So to prevent this problem from happening again, I am proposing the immediate creation of a NAT Traversal Directorate which will do this kind of reviews, and I am also volunteering to be the first member of this directorate. Thanks. --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --OalA7Xn7rObmh646LiXSV0ow4a7DCVcxH 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/ iQEcBAEBAgAGBQJTagMsAAoJEMUNRP98lsiX5FoIAJLp42AnmFsLw1HGUZh1NpvP wmDkHKviaUU3O8YUkFZkq052xeAGCl2axEX+O7Jk1w0Yt9xZY8juZAukEt1TWAyI SAZsi3jadDDWElOABH5GmW01GB19HlrCMyu0HDAgXJIER8zkGDi44kiSsHSYnj/W RC9wFUv+8NkWeRG4gbgSYE5Xz7LAUYFy1PXTuUglJGk12ojHAALAx3CHYiqGEbfV ogrTOCw1LtziYD9PMdXtxc1RKp5nKnVlSs2Rdz/hokpzJEwJugKg5itqWWtI/Kq/ iH7cwDkRxYbaWqzMHPO/ay+iBMmVvk3YfuHkLmV7jxlhbLexu+MMwM2iCzyat8s= =ZrWf -----END PGP SIGNATURE----- --OalA7Xn7rObmh646LiXSV0ow4a7DCVcxH-- From nobody Wed May 7 10:49: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 2BBED1A08B1 for ; Wed, 7 May 2014 10:49:55 -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 A0Sl8Qd2T490 for ; Wed, 7 May 2014 10:49:52 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id F1EDA1A08A7 for ; Wed, 7 May 2014 10:49:49 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id x48so1378729wes.36 for ; Wed, 07 May 2014 10:49:45 -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=8m6a4VVe9Auw+re8qndeWi6RbVqnNpJGttqODPhC8gY=; b=Tb8+YdWpBx+3B0KuCXdzOM7ZlRfuqYRQEhMUYDKwHyNnhS6PdlTOi28XbLASecHGhA vTJ2dylo/iwzTXagcJa0M5bJpTd503VpdT5GZWvrN2SJfU85iojlscHAgMOqlmCASsRu XlE9zo7nkOwh7bTvEj4gfbFSSyAb+ty+cpvzhp6UyfOzUujVUzLCQhbLswYd+7w1Xx9s tQYcY++XZnyGt/yGo7TbzLINaOTdrrTSyi9dS9dDvHP5b9MbgPise8KaLtXbWvlyKOg1 jm01kMWY+AVs91yuUtnre4SF3QRute12gtQ2iogYqFQ9V5eb1y8C8ajGm4YqkBQ/TUYN FHzw== MIME-Version: 1.0 X-Received: by 10.194.84.101 with SMTP id x5mr9360608wjy.52.1399484985223; Wed, 07 May 2014 10:49:45 -0700 (PDT) Received: by 10.217.152.200 with HTTP; Wed, 7 May 2014 10:49:45 -0700 (PDT) In-Reply-To: <5368BF90.2070307@getjive.com> References: <5368BF90.2070307@getjive.com> Date: Wed, 7 May 2014 12:49:45 -0500 Message-ID: From: Alan Johnston To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=047d7bb04dce69b1ee04f8d2fd4f Archived-At: http://mailarchive.ietf.org/arch/msg/tram/K_YfIa_sCqF7g2chvwh0lo44gCw Cc: "tram@ietf.org" Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 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, 07 May 2014 17:49:55 -0000 --047d7bb04dce69b1ee04f8d2fd4f Content-Type: text/plain; charset=UTF-8 Marc, Thanks for the review. See my comments below. - Alan - On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin wrote: > A1. Intended Status: Informational > > Shouldn't this be Standard Track? > > Yes. > A2. Section 1, 2nd paragraph, last sentence: "as generating the > response..." > > I do not think that the reason for no authentication for the NAT > Discovery Usage is because it is less work, but because there is no > resource to protect so adding more work does not make sense. > > I disagree that there is *no* resource to protect. A STUN server might be minimal resources, but not none. If a simple authentication scheme were available, I'm sure some people would use it so they could minimize the cost of their server footprint by ensuring that only authenticated users were utilizing it. I will add some text pointing out that the minimal resources. > A3. Section 1, 8th paragraph > > I do not think that the ORIGIN should be used to select the certificate > when (D)TLS is used. First it does not work with DANE, as when an SRV > (and probably NAPTR too, but that's undefined yet) RR redirects to a > different domain, the domain to be checked with is the host name, not > the service domain (see draft-ietf-dane-srv). For non-DANE cases, I > think that the correct way to select the certificate is to use SNI. > The draft does not suggest that ORIGIN be used to select certificates - as Oleg pointed out it isn't possible. This paragraph was describing how RFC 6066 does not solve the problem, as had been suggested on the list. > > So I would suggest to restrict the normative use of ORIGIN only to > select realms. > > A4. Section 2.2. ORIGIN attribute usage > > The text does not say if the ORIGIN attribute should/can be provided > after the authentication (i.e. refresh, data packets, etc...) > Currently, the text says SHOULD include, for a conformant client. For logging, it has value even after the initial authentication. > > A5. Section 2.2. Mandatory support for server > > How a TURN server that requires the usage of ORIGIN can signal this? > > Right now there is no way to do this. I agree with Oleg that it is up to the server what to do if ORIGIN is no present. > A6. Section 2. Other Usages > > I think that other STUN Usages should be listed after section 2.3: > > - Media Keep-Alive Usage (Section 20 of RFC5245) > - SIP Keep-Alive Usage (RFC 5626) > - NAT Behavior Discovery Usage (RFC 5780) > > I'll take a look at these scenarios. I suspect that it would be a reasonable usage for client-to-server usages, but not for peer-to-peer usages. > A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute > is present, the contents of the ORIGIN attribute are integrity protected." > > Which never happen in the usages listed in the document: for section > 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is > needed to select the realm, so the ORIGIN is sent before it can be > protected. Perhaps 2.2 should say that if ORIGIN was sent to select the > realm, it MUST be repeated at identical on the second Allocate (the one > that has an M-I) and that the server MUST reject it if it is not > identical to the first one. Not sure it matters though. > > I agree that there is no integrity protection of the ORIGIN attribute (or any other attribute) until after authentication. However, ORIGIN can be used both before and after authentication. I'll review this text and make sure this is clear. I don't believe we need any special rules, as this applies to any STUN attribute. > Nits > ---- > > - Section 2, 2nd paragraph: "The number used for the this in the ..." > > Does not parse. > The middle "the" shouldn't be there. > > -- > Marc Petit-Huguenin > Developer | Jive Communications, Inc. > Jive.com | marcph@getjive.com > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7bb04dce69b1ee04f8d2fd4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Marc,

Thanks for the review. =C2=A0See = my comments below.

- Alan -


On Tue, May 6, 2014 at 5:55 AM= , Marc Petit-Huguenin <marcph@getjive.com> wrote:
A1. Intended Status: Informational

Shouldn't this be Standard Track?


Yes.
=C2=A0
A2. Section 1, 2nd paragraph, last sentence: "as generating the respon= se..."

I do not think that the reason for no authentication for the NAT
Discovery Usage is because it is less work, but because there is no
resource to protect so adding more work does not make sense.


I disagree that there is *no* resource= to protect. =C2=A0A STUN server might be minimal resources, but not none. = =C2=A0If a simple authentication scheme were available, I'm sure some p= eople would use it so they could minimize the cost of their server footprin= t by ensuring that only authenticated users were utilizing it. =C2=A0I will= add some text pointing out that the minimal resources.
=C2=A0
A3. Section 1, 8th paragraph

I do not think that the ORIGIN should be used to select the certificate
when (D)TLS is used. =C2=A0First it does not work with DANE, as when an SRV=
(and probably NAPTR too, but that's undefined yet) RR redirects to a different domain, the domain to be checked with is the host name, not
the service domain (see draft-ietf-dane-srv). =C2=A0For non-DANE cases, I think that the correct way to select the certificate is to use SNI.

The draft does not suggest that ORIGIN be used= to select certificates - as Oleg pointed out it isn't possible. =C2=A0= This paragraph was describing how RFC 6066 does not solve the problem, as h= ad been suggested on the list.
=C2=A0

So I would suggest to restrict the normative use of ORIGIN only to
select realms.

A4. Section 2.2. ORIGIN attribute usage

The text does not say if the ORIGIN attribute should/can be provided
after the authentication (i.e. refresh, data packets, etc...)

Currently, the text says SHOULD include, for a confo= rmant client. =C2=A0For logging, it has value even after the initial authen= tication.
=C2=A0

A5. Section 2.2. =C2=A0Mandatory support for server

How a TURN server that requires the usage of ORIGIN can signal this?


Right now there is no way to do this. = =C2=A0I agree with Oleg that it is up to the server what to do if ORIGIN is= no present.
=C2=A0
A6. Section 2. Other Usages

I think that other STUN Usages should be listed after section 2.3:

- Media Keep-Alive Usage (Section 20 of RFC5245)
- SIP Keep-Alive Usage (RFC 5626)
- NAT Behavior Discovery Usage (RFC 5780)


I'll take a look at these scenario= s. =C2=A0I suspect that it would be a reasonable usage for client-to-server= usages, but not for peer-to-peer usages.
=C2=A0
A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute=
is present, the contents of the ORIGIN attribute are integrity protected.&q= uot;

Which never happen in the usages listed in the document: =C2=A0for section<= br> 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is
needed to select the realm, so the ORIGIN is sent before it can be
protected. =C2=A0Perhaps 2.2 should say that if ORIGIN was sent to select t= he
realm, it MUST be repeated at identical on the second Allocate (the one
that has an M-I) and that the server MUST reject it if it is not
identical to the first one. =C2=A0Not sure it matters though.


I agree that there is no integrity pro= tection of the ORIGIN attribute (or any other attribute) until after authen= tication. =C2=A0However, ORIGIN can be used both before and after authentic= ation. =C2=A0I'll review this text and make sure this is clear. =C2=A0I= don't believe we need any special rules, as this applies to any STUN a= ttribute.
=C2=A0
Nits
----

- Section 2, 2nd paragraph: "The number used for the this in the ...&q= uot;

Does not parse.

The middle "the&qu= ot; shouldn't be there.
=C2=A0

--
Marc Petit-Huguenin
Developer =C2=A0| =C2=A0Jive Communications, Inc.
Jive.com =C2=A0| =C2=A0marcph@getjive= .com


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


--047d7bb04dce69b1ee04f8d2fd4f-- From nobody Wed May 7 23:38: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 280FC1A0527 for ; Wed, 7 May 2014 23:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4Uk_CxU7O5Jt for ; Wed, 7 May 2014 23:38:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE9F1A04DC for ; Wed, 7 May 2014 23:38:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79a86d0000010e9-44-536b26693e70 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 14.62.04329.9662B635; Thu, 8 May 2014 08:38:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.174.1; Thu, 8 May 2014 08:38:32 +0200 Message-ID: <536B2668.7070405@ericsson.com> Date: Thu, 8 May 2014 08:38:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marc Petit-Huguenin , References: <536734AA.2050006@ericsson.com> <536A0326.7040704@getjive.com> In-Reply-To: <536A0326.7040704@getjive.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+JvjW6mWnawwZYFEhaf1p9ms/iw9gKb A5NHx5P5bB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp41lBWcEiz4sD824wNjPcUuhg5OSQETCQm nHrDDmGLSVy4t56ti5GLQ0jgKKPEv/XL2CGcZYwSv/o62UCqeAW0JZbO/s4IYrMIqEjsWtIP ZrMJWEjc/NEIViMqECyx4eFfdoh6QYmTM5+wgNgiArYSt66+AqsXFgiQmD1rN1iNkICXxP/f h8DinEDz1y+ax9rFyAF0kbhET2MQSJhZQE9iytUWRghbXqJ562xmiFZtiYamDtYJjIKzkGyb haRlFpKWBYzMqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECg/Xglt9WOxgPPnc8xCjAwajE w7uwJCtYiDWxrLgy9xCjNAeLkjjvpEXuwUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYlwbb Wvd8T9mbt+lXmP71Pt3PFrrbdjKwMpRr7q8oCrj+/cxz+88KqucZH+92+RCy4fH7rzv+arWW c4X+8C9K1/5wTsmRPSP11MQLiwUmxbK5dyxfZCgzkWFLKv+lsDudms0nn7i/vjyzoTpfomJ+ xvH1ktPrWw+mFzQdvOW2+k3nkYA0Ht8iJZbijERDLeai4kQAEIKXHDcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/tram/iRXgU5glSNCzvGivDPfzJAV8v3I Subject: Re: [tram] Request to update STUN's IANA registration in STUNbis work 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, 08 May 2014 06:38:41 -0000 Hi, See inline. On 2014-05-07 11:55, Marc Petit-Huguenin wrote: > Hi Magnus, > > On 5/5/14, 12:50 AM, Magnus Westerlund wrote: >> WG, >> >> The AVTCORE WG have had a discussion regarding DTLS-SRTP (RFC >> 5764) and STUN's IANA registrations. To ensure that the IANA >> rules are accurate and reflect the reality of the environment >> STUN is operating in today, there appear to be a desire to >> request that STUN's IANA rules are changed. >> >> With the approval of RFC 5764 it was created a value overlap in >> the use cases where DTLS-SRTP and STUN are co-existing on the >> same transport flow. This value overlap exists for any method >> value outside the range 0-127 for each class of STUN methods. >> Thus to avoid any collisions in future registrations it appears >> prudent to restrict method registrations to this range to avoid >> collisions in the cases where one uses STUN and DTLS-SRTP. >> > > I do not think this is the right thing to do. The problem is that > what RFC 5764 did was allocating most of the IETF Review STUN > Method codepoints without IETF review and all of the Designated > Expert STUN Method codepoints without expert review, this last > point being the main problem in my opinion, as now nobody can > request one of those. Well, done is done. And it is an IETF consensus document. It likely should have had more review when it was being pre-paired for publication. I agree that the designated expert review range is in serious question for now. We should clearly have discussion on what to do. > > So I have two proposals, first to fix the problem itself: > > 1. An additional problem with RFC 5764 is that not only it > requisitioned most of the STUN methods codepoints, but it did it > unnecessarily. Instead of this: > > +----------------+ | 127 < B < 192 -+--> forward to RTP | > | packet --> | 19 < B < 64 -+--> forward to DTLS | > | | B < 2 -+--> forward to STUN +----------------+ > > It should have said this: > > +----------------+ | 127 < B < 192 -+--> forward to RTP | > | packet --> | 19 < B < 64 -+--> forward to DTLS | > | | B < 20 -+--> forward to STUN +----------------+ > > That would have left 1280 codepoints instead of a mere 128. > > So my proposal is that AVTCORE write a standard track RFC updating > RFC 5764 with the modification above, and with a request to modify > the IANA registry so that the new RFC Review range is 0x000-0x2FF > and the new Designated Expert range is 0x300-0x4FF. Yes, the question is how many is really needed? If TRAM thinks it necessary to have 1280 per class then I guess we will have to update what RFC 5764 says. I will note two things about this. 1. Considering that TRAM WG does have an WG item to update STUN, it appears wrong that AVTCORE updates the IANA section of STUN. It appears much wiser to have the future IANA section be part of the actual STUN RFC in effect. Thus, I really like TRAM to do that part of the work. 2. Extending the STUN processing range in DTLS-SRTP implementations is on paper just adding a character. However, the legacy implications on the deployed implementations needs to be considered. I would fear that anyone getting the first codepoint in the range corresponding to B values of 2-19 might get quite irritated due to compatibility issues. I think we need to check with existing implementations what the impact of this is. Further I note that if we need to update RFC 5764 we need both a stuckee to do the editing and AD approval for this. I think the AVTCORE charter is fine to take on such an item. > > 2. This problem is basically a failure in having RFC 5764 reviewed > by NAT traversal experts before its publication. So to prevent > this problem from happening again, I am proposing the immediate > creation of a NAT Traversal Directorate which will do this kind of > reviews, and I am also volunteering to be the first member of this > directorate. > May be a good idea, however if RFC 5764 wasn't reviewed sufficiently then it was an issue with the leadership as well as the participants, it was not the lack of venues. At the time RFC 5764 went through IETF last call (September 2008) as well as WG last call (August 2008) BEHAVE WG was very active. One failure of ADs and WG chairs was to not inform BEHAVE and ensure that it was reviewed from that perspective. The main issue with cross-review and directorates is that someone needs to ensure that they do happen, either by requesting review with the right entity, or that the entity finds the document itself. Both requires work and knowledge. And I am quite certain that the TSV ADs are happy to ad you to the transport directorate in your capacity as NAT traversal expert. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu May 8 03:30: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 881461A0297 for ; Thu, 8 May 2014 03:30:33 -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 hVhCHTY-y7em for ; Thu, 8 May 2014 03:30:29 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 34C0D1A0188 for ; Thu, 8 May 2014 03:30:29 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so2308711igd.14 for ; Thu, 08 May 2014 03:30:24 -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=nppgfDujrzO1bLUIuBgfhU7TMhadKu1ktkSG0RsYcn0=; b=Vg82O9olj7votslmh05SDe5B71Wa+xmDc/SpCF/e0mWBaFqoB6w8HOzSEdjeBBBq56 XM2zVb5T+H5BZWLfZu7g2QwGpfZ/0mmbYJsE/G3z3SuiJXTnag5vrpfkcyrQ0h+m1uNJ p14v+PeI0kRlP49TA5q8QKrQ196Qe92c75/as= 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=nppgfDujrzO1bLUIuBgfhU7TMhadKu1ktkSG0RsYcn0=; b=MWQ+xl8TSSeVUZHxFYo8EJqt9y826t1kPolxF5OVZYMF/i1k7cI24+yLvcESttzSm4 3ghq6j9c5stTCcxkn/BVUpis3JoGtdWamjnYmHppcqiJrwjDjx68c8o26xO8cLBN6VjC Wp9BWWz9+Q5hNzIKBT0LG2bE0Nc/dQm71wGCI2iWNjko67Hkwn87MZ1nYQuiD9WmTiKS welljAo39zWxprz3Zb20oJa2ida3trEc2cJcR61tGMTyku4bhaW4/ph/L8zxw2wv1Dsx KB3U51SxLYl5R3B9QJyMmGti/G6Rz1nPIKw3bB8hy2Bj6FDBx1f9YIkRr1qUQWq4hzXd jCmw== X-Gm-Message-State: ALoCoQmjzbegcKrMacHzwYLUy9iCIy1JnDsTyqtn5BWw6HacetiZTvTedDjJZtTe+W1pNmOiMmAU X-Received: by 10.50.43.170 with SMTP id x10mr54642175igl.36.1399545024576; Thu, 08 May 2014 03:30:24 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id i16sm4623187igf.11.2014.05.08.03.30.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 May 2014 03:30:23 -0700 (PDT) Message-ID: <536B5CB8.90801@getjive.com> Date: Thu, 08 May 2014 04:30:16 -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: Magnus Westerlund , tram@ietf.org References: <536734AA.2050006@ericsson.com> <536A0326.7040704@getjive.com> <536B2668.7070405@ericsson.com> In-Reply-To: <536B2668.7070405@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="22TptRexu7uL46i901mFCE8ujnI5fSiLE" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wCKg0q3MJYSE4h5OV5y6vTfB4u8 Subject: Re: [tram] Request to update STUN's IANA registration in STUNbis work 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, 08 May 2014 10:30:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --22TptRexu7uL46i901mFCE8ujnI5fSiLE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inline. On 5/8/14, 12:38 AM, Magnus Westerlund wrote: > Hi, >=20 > See inline. >=20 > On 2014-05-07 11:55, Marc Petit-Huguenin wrote: >> Hi Magnus, >> >> On 5/5/14, 12:50 AM, Magnus Westerlund wrote: >>> WG, >>> >>> The AVTCORE WG have had a discussion regarding DTLS-SRTP (RFC >>> 5764) and STUN's IANA registrations. To ensure that the IANA >>> rules are accurate and reflect the reality of the environment >>> STUN is operating in today, there appear to be a desire to >>> request that STUN's IANA rules are changed. >>> >>> With the approval of RFC 5764 it was created a value overlap in >>> the use cases where DTLS-SRTP and STUN are co-existing on the >>> same transport flow. This value overlap exists for any method >>> value outside the range 0-127 for each class of STUN methods. >>> Thus to avoid any collisions in future registrations it appears >>> prudent to restrict method registrations to this range to avoid >>> collisions in the cases where one uses STUN and DTLS-SRTP. >>> >> >> I do not think this is the right thing to do. The problem is that >> what RFC 5764 did was allocating most of the IETF Review STUN >> Method codepoints without IETF review and all of the Designated >> Expert STUN Method codepoints without expert review, this last >> point being the main problem in my opinion, as now nobody can >> request one of those. >=20 > Well, done is done. And it is an IETF consensus document. It likely > should have had more review when it was being pre-paired for publicatio= n. >=20 > I agree that the designated expert review range is in serious question > for now. We should clearly have discussion on what to do. >=20 >> >> So I have two proposals, first to fix the problem itself: >> >> 1. An additional problem with RFC 5764 is that not only it >> requisitioned most of the STUN methods codepoints, but it did it >> unnecessarily. Instead of this: >> >> +----------------+ | 127 < B < 192 -+--> forward to RTP | >> | packet --> | 19 < B < 64 -+--> forward to DTLS | >> | | B < 2 -+--> forward to STUN +----------------+ >> >> It should have said this: >> >> +----------------+ | 127 < B < 192 -+--> forward to RTP | >> | packet --> | 19 < B < 64 -+--> forward to DTLS | >> | | B < 20 -+--> forward to STUN +----------------+ >> >> That would have left 1280 codepoints instead of a mere 128. >> >> So my proposal is that AVTCORE write a standard track RFC updating >> RFC 5764 with the modification above, and with a request to modify >> the IANA registry so that the new RFC Review range is 0x000-0x2FF >> and the new Designated Expert range is 0x300-0x4FF. >=20 > Yes, the question is how many is really needed? If TRAM thinks it > necessary to have 1280 per class then I guess we will have to update > what RFC 5764 says. >=20 > I will note two things about this. >=20 > 1. Considering that TRAM WG does have an WG item to update STUN, it > appears wrong that AVTCORE updates the IANA section of STUN. It > appears much wiser to have the future IANA section be part of the > actual STUN RFC in effect. Thus, I really like TRAM to do that part of > the work. Fair enough. >=20 > 2. Extending the STUN processing range in DTLS-SRTP implementations is > on paper just adding a character. However, the legacy implications on > the deployed implementations needs to be considered. I would fear that > anyone getting the first codepoint in the range corresponding to B > values of 2-19 might get quite irritated due to compatibility issues. > I think we need to check with existing implementations what the impact > of this is. Right. One way of doing that would be to write a short draft, then collect RFC 6982 statements from implementers and decide on what to do from there. >=20 > Further I note that if we need to update RFC 5764 we need both a > stuckee to do the editing and AD approval for this. I think the > AVTCORE charter is fine to take on such an item. I may work on the AVTCORE and the TRAM drafts >=20 >> >> 2. This problem is basically a failure in having RFC 5764 reviewed >> by NAT traversal experts before its publication. So to prevent >> this problem from happening again, I am proposing the immediate >> creation of a NAT Traversal Directorate which will do this kind of >> reviews, and I am also volunteering to be the first member of this >> directorate. >> >=20 > May be a good idea, however if RFC 5764 wasn't reviewed sufficiently > then it was an issue with the leadership as well as the participants, > it was not the lack of venues. At the time RFC 5764 went through IETF > last call (September 2008) as well as WG last call (August 2008) > BEHAVE WG was very active. One failure of ADs and WG chairs was to not > inform BEHAVE and ensure that it was reviewed from that perspective. >=20 > The main issue with cross-review and directorates is that someone > needs to ensure that they do happen, either by requesting review with > the right entity, or that the entity finds the document itself. Both > requires work and knowledge. Yes. The problem here is very specific: Because of the nature of NAT traversal protocols (they generally need to run on the exact same IP address/port than the protocol they try to help, to be able to keep the NAT ports open), there is a need for multiplexing. In this case the multiplexing rules are incorrect, but we can see that it is not specific to STUN. For example the multiplexing rules in RFC 5764 says that if the first byte is between 20 and 63, then it should be forwarded to DTLS. Doesn't that mean that the IANA registry for TLS ContentType should also be restricted to values between 20 and 63? So what we need is to be able to review from a multiplexing point of view all the drafts that will allocate a new TLS ContentType, all the drafts that will allocate a new STUN Method (and all the drafts that will define a new version of RTP, but that less likely), plus all the drafts that define new protocols to be multiplexed inside RFC 5764 (using the non-allocated ranges: 2-19, 64-127 and 192-255). I suppose that a similar analysis needs to be done for other multiplexing rules related to NAT traversal, if they exist. --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --22TptRexu7uL46i901mFCE8ujnI5fSiLE 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/ iQEcBAEBAgAGBQJTa1y9AAoJEMUNRP98lsiXWqoH/1/knQ5UUMmNddqtfQJC4aJi stk0X2lFIxjygavRqqLlqNipu0UXIsNY0BOTObYlW9ko8+MzP7Vmxp1qwjP9K/R9 981bEM/0QY81vWuKKuNBh4RFdMfDg3zvRECDyIuJrdWLS7Hb1kNU2clNrQ/YInqO YTBoNJRckbwXBszCwVABnzlrYS8vBipzdyJzP08Okpf+L3mg1y5UT7ggczR5LQxF fHY32NrPCC4vzMK++kdrz8ddHtjJv+5Zy8aOPYmngBYyfZ2tlbOR8wZscLynLcex 5EdEvpjddNd8f62qJZbp25muSnbDTjUipi/BeIDYFjsJX7spbuYWjWaXiNz41go= =qy11 -----END PGP SIGNATURE----- --22TptRexu7uL46i901mFCE8ujnI5fSiLE-- From nobody Mon May 12 07:35:27 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 ADF841A0247 for ; Mon, 12 May 2014 07:35:24 -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=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 hUlAZuac9per for ; Mon, 12 May 2014 07:35:22 -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 B63851A01EA for ; Mon, 12 May 2014 07:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2686; q=dns/txt; s=iport; t=1399905317; x=1401114917; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=W40LXbZOUFSOaXxS9+LxoAYsfU1FLbKn0a1xropBTgY=; b=cX950CEG+dKrmLVzU7CA+6DGxvWOPZaZIClN47S8i0yXZMUw4hX83ywA AhpxuawhHfdoSI5Dvg1AZnWkWc3LlMbZOltpJPM+A04z70jqIDGGWZAGM 2orQ5VsjVepZsfWTvo3AbXGzWLS9nF8F1oSbQ8rUWgoi+xmumCvj8j/3I I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwHAKPbcFOtJV2a/2dsb2JhbABZgwZPUQeCZ8MGARl/FnSCJQEBAQQjEUMOBgEIEQQBAQMCBh0DAgQwFAEGAQEFBAEEEwgBiDgIBZtvjyCjfxeBKox3PoJvNoEVBJsEkUuDNm2BAiQc X-IronPort-AV: E=Sophos;i="4.97,1035,1389744000"; d="scan'208";a="43071438" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 12 May 2014 14:35:16 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4CEZGaw028722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 12 May 2014 14:35:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 12 May 2014 09:35:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-reddy-tram-turn-third-party-authz-02.txt Thread-Index: Ac9t72E8fCFVGXAESpiaMHsBXoVrSw== Date: Mon, 12 May 2014 14:35:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A243306DE@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.75.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vPBrqXXQ3uZt6Zi9hsSNMuq8F_s Subject: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-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, 12 May 2014 14:35:24 -0000 UmV2aXNlZCBkcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHogaGFzIGJlZW4g cHVibGlzaGVkLiAgQWRkcmVzc2VzIGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gQnJhbmRvbiBhbmQg T2xlZy4gDQpGdXJ0aGVyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0K VGhhbmtzIGFuZCBSZWdhcmRzLA0KLUF1dGhvcnMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE1heSAxMiwgMjAxNCA3OjU4IFBNDQpUbzogUmFt IE1vaGFuIFIgKHJtb2hhbnIpOyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KTsgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IEp1c3RpbiBV YmVydGk7IEp1c3RpbiBVYmVydGk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFJhbSBN b2hhbiBSIChybW9oYW5yKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDIudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0w Mi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJl ZGR5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXJl ZGR5LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoeg0KUmV2aXNpb246CTAyDQpUaXRsZToJCVRV Uk4gRXh0ZW5zaW9uIGZvciBUaGlyZCBQYXJ0eSBBdXRob3JpemF0aW9uDQpEb2N1bWVudCBkYXRl OgkyMDE0LTA1LTEyDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNg0K VVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXJlZGR5LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMi50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yZWRkeS10cmFtLXR1cm4t dGhpcmQtcGFydHktYXV0aHovDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAyDQpEaWZmOiAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcmVkZHktdHJh bS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVu dCBwcm9wb3NlcyB0aGUgdXNlIG9mIE9BdXRoIHRvIG9idGFpbiBhbmQgdmFsaWRhdGUNCiAgIGVw aGVtZXJhbCB0b2tlbnMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgVFVSTiBhdXRoZW50aWNhdGlvbi4g IFRoZSB1c2FnZQ0KICAgb2YgZXBoZW1lcmFsIHRva2VucyBlbnN1cmUgdGhhdCBhY2Nlc3MgdG8g YSBUVVJOIHNlcnZlciBjYW4gYmUNCiAgIGNvbnRyb2xsZWQgZXZlbiBpZiB0aGUgdG9rZW5zIGFy ZSBjb21wcm9taXNlZCwgYXMgaXMgdGhlIGNhc2UgaW4NCiAgIFdlYlJUQyB3aGVyZSBUVVJOIGNy ZWRlbnRpYWxzIG11c3QgYmUgc3BlY2lmaWVkIGluIEphdmFzY3JpcHQuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri May 16 11:28:41 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 4D28B1A030D for ; Fri, 16 May 2014 11:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_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 r9j84JMZ30jJ for ; Fri, 16 May 2014 11:19:06 -0700 (PDT) Received: from nomis80.org (nomis80.org [23.92.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 894A81A02EF for ; Fri, 16 May 2014 11:19:06 -0700 (PDT) Received: from [IPv6:2001:470:1d:bc0:3075:8c58:53ee:f195] (unknown [IPv6:2001:470:1d:bc0:3075:8c58:53ee:f195]) by nomis80.org (Postfix) with ESMTPSA id 90E7210EA6 for ; Fri, 16 May 2014 18:20:00 +0000 (UTC) Message-ID: <53765692.60509@per.reau.lt> Date: Fri, 16 May 2014 14:18:58 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tram@ietf.org References: <536734AA.2050006@ericsson.com> <536A0326.7040704@getjive.com> In-Reply-To: <536A0326.7040704@getjive.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2QyG1BxCDMH6Y1yZaGeqqGSQuOs Subject: Re: [tram] Request to update STUN's IANA registration in STUNbis work 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, 16 May 2014 18:19:08 -0000 > +----------------+ > | 127 < B < 192 -+--> forward to RTP > | | > packet --> | 19 < B < 64 -+--> forward to DTLS > | | > | B < 2 -+--> forward to STUN > +----------------+ Here's my reasoning... I'm pretty sure the RFC 5764 authors looked at RFC 3489, for which B < 2 would have been correct. The fact that draft-mcgrew-tls-srtp-00, which did contain the above graph, was published long before RFC 5389 was reinforces that hypothesis. With RFC 5389, B < 64 would be necessary, ergo the conflict with DTLS. I'm unable to find a justification for 19 < B < 64 --> DTLS. Can anyone please spell it out for me? I'm just going to assume it is correct. Fact: There are currently no registered STUN methods which would actually cause STUN packets to be wrongly forwarded to DTLS by an implementation of RFC 5764. Fact: B < 2 limits the number of STUN methods to 128. There are currently 13 methods registered. I know of no plans to register many STUN methods such that a limit of 128 would become problematic. Fact: If STUN-bis restricts to 128 the range of STUN methods, current implementations, of either STUNv1, STUNv2, or RFC 5764, will *not* need to be modified. STUN-bis could split on 0-63 for IETF Review and 64-127 for Designated Expert so that we can keep our dual registration procedures. Opinion: The only disadvantage I can see to making this change in STUN-bis would be a loss of STUN method range. I think we can live with it. If at some point we can't live with it anymore, which I doubt will ever happen, then we would need to revise both RFC 5764 and STUN-bis. There's no need for a revision of RFC 5764 now. Simon From nobody Fri May 16 12:37: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 59DE81A01EE for ; Fri, 16 May 2014 12:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM4jmOdDAjHQ for ; Fri, 16 May 2014 12:37:05 -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 7A2E31A015F for ; Fri, 16 May 2014 12:37:05 -0700 (PDT) Received: from [IPv6:2001:5c0:1101:2d00:74c0:8cb4:a9d9:6159] (unknown [IPv6:2001:5c0:1101:2d00:74c0:8cb4:a9d9:6159]) (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 515F220731; Fri, 16 May 2014 21:36:54 +0200 (CEST) Message-ID: <537668D3.3020501@acm.org> Date: Fri, 16 May 2014 13:36:51 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Simon Perreault , tram@ietf.org References: <536734AA.2050006@ericsson.com> <536A0326.7040704@getjive.com> <53765692.60509@per.reau.lt> In-Reply-To: <53765692.60509@per.reau.lt> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZdJX6qINi649En6UPIGEBFGiXJE Subject: Re: [tram] Request to update STUN's IANA registration in STUNbis work 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, 16 May 2014 19:37:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/16/2014 12:18 PM, Simon Perreault wrote: >> +----------------+ | 127 < B < 192 -+--> forward to RTP | >> | packet --> | 19 < B < 64 -+--> forward to DTLS | | | >> B < 2 -+--> forward to STUN +----------------+ > > Here's my reasoning... > > I'm pretty sure the RFC 5764 authors looked at RFC 3489, for which B < 2 > would have been correct. The fact that draft-mcgrew-tls-srtp-00, which did > contain the above graph, was published long before RFC 5389 was reinforces > that hypothesis. But the STUN usage is ICE connectivity check, which explicitly forbids RFC 3489 (see section 7 of RFC 5245). > > With RFC 5389, B < 64 would be necessary, ergo the conflict with DTLS. > > I'm unable to find a justification for 19 < B < 64 --> DTLS. Can anyone > please spell it out for me? I'm just going to assume it is correct. It's not, as it restricts TLS ContentType: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5. At a minimum 0-19 and 64-255 should be marked as reserved. > > Fact: There are currently no registered STUN methods which would actually > cause STUN packets to be wrongly forwarded to DTLS by an implementation of > RFC 5764. > > Fact: B < 2 limits the number of STUN methods to 128. There are currently > 13 methods registered. I know of no plans to register many STUN methods > such that a limit of 128 would become problematic. TURN had a limited deployment until now. With WebRTC I expect more TURN extensions coming and I myself have some currently being designed. So that's certainly not the right time to restrict the number of methods possible. > > Fact: If STUN-bis restricts to 128 the range of STUN methods, current > implementations, of either STUNv1, STUNv2, or RFC 5764, will *not* need to > be modified. STUN-bis could split on 0-63 for IETF Review and 64-127 for > Designated Expert so that we can keep our dual registration procedures. Maybe. The main problem is that (implicit) assignments were done in TWO IANA registries without following the process. That's what need to stop. > > Opinion: The only disadvantage I can see to making this change in STUN-bis > would be a loss of STUN method range. I think we can live with it. If at > some point we can't live with it anymore, which I doubt will ever happen, > then we would need to revise both RFC 5764 and STUN-bis. There's no need > for a revision of RFC 5764 now. Or, we can reclaim 2-63 for STUN now and not have to pull an ugly EDNS(x)-like workaround later. - -- 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 iQIcBAEBCAAGBQJTdmjGAAoJECnERZXWan7EocgQALGMzXkX/hKqHJjZafA+L9BK LmhWPC/ABPGJspZXmaZSVMV/jYsyjUK10OiaxpR8VKM0yvaE5MrUXrRT5uQll/G2 6/tcrHXjs4lLhhAAfHmJzQu3tv8UYnTEKLJq7CNrr0Uoa5vRZtgiRMXmmDZH8IUn alB2gRtHZR6jiBeWLKogdUaXOzIzIwnu86E8+HgeWL+vHRuc6gX1uiZZ+mr0MPzR x0BlZXatCOSN7Ho/5DqgWsM+WMZXKS+UnfV58kjVk8Ycuk78ETIo+kzOc7qWcNfP f0bq2mTDKWDQq6oyhJZ6z5s23v+EiemSTy5H5iYJ7f3iahnbS3yx6F0pni6dG+EK GzeANH4riPwJoZvx5zmdXUBpnbMjUDxUZIs1H+M3ETlT3T93hQzaHDI/PVjMG3TQ 9AHqDyRfeI9J0noeNp1KO2nznxM1WaTOMTA36X2JuMgmqO04LpzUuNPw79HMVDyX pnWfPoM+WrFid/iK9FV9L1t8zMcOHblaKtMARdM/h9jvrk8Lygjyf3ihomp7+oc/ GQr3yIx73vcJZ8aRsWNqjKWpsnMhU3/jPeunH52RqbvWjhXgS6L5XzIWiRQBujcZ 1FlipuMIKauIrwGdpNM7Wu5l42Ysh06pf1i0SYeLGXTLJwzZ3IK9YzZrEMpgM6O/ crLLyWye/L9GqbVK+sWG =qfng -----END PGP SIGNATURE----- From nobody Fri May 16 14:24:48 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 352551A0151 for ; Fri, 16 May 2014 14:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 cabFvsx6dZfc for ; Fri, 16 May 2014 14:24:44 -0700 (PDT) Received: from nomis80.org (nomis80.org [IPv6:2600:3c03::f03c:91ff:fe69:7108]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9191A0157 for ; Fri, 16 May 2014 14:24:44 -0700 (PDT) Received: from [IPv6:2001:470:1d:bc0:3075:8c58:53ee:f195] (unknown [IPv6:2001:470:1d:bc0:3075:8c58:53ee:f195]) by nomis80.org (Postfix) with ESMTPSA id BC7EC10EA6; Fri, 16 May 2014 21:25:39 +0000 (UTC) Message-ID: <53768217.7070909@per.reau.lt> Date: Fri, 16 May 2014 17:24:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marc Petit-Huguenin , tram@ietf.org References: <536734AA.2050006@ericsson.com> <536A0326.7040704@getjive.com> <53765692.60509@per.reau.lt> <537668D3.3020501@acm.org> In-Reply-To: <537668D3.3020501@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/NY31ultrtavk1y1LtUNUOGbjPno Subject: Re: [tram] Request to update STUN's IANA registration in STUNbis work 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, 16 May 2014 21:24:46 -0000 Le 2014-05-16 15:36, Marc Petit-Huguenin a écrit : >> I'm unable to find a justification for 19 < B < 64 --> DTLS. Can anyone >> please spell it out for me? I'm just going to assume it is correct. > > It's not, as it restricts TLS ContentType: > > http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5. > > At a minimum 0-19 and 64-255 should be marked as reserved. Wow. So both DTLS and STUN are equally affected by RFC 5764. If we restrict STUN to work with RFC 5764, it would make sense that the DTLS folks do the same. Also, it now seems impossible to just fix RFC 5764 on its own without touching at least DTLS. The DTLS folks need to get involved in this discussion... Simon From nobody Sun May 18 05:43: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 DE4F51A005C for ; Sun, 18 May 2014 05:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] 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 fQl-1Un2X2dM for ; Sun, 18 May 2014 05:43:42 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C13D1A005A for ; Sun, 18 May 2014 05:43:40 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201405181443371019; Sun, 18 May 2014 14:43:37 +0200 From: "Karl Stahl" To: "'Prashanth Patil \(praspati\)'" , , "'Simon Perreault'" References: <20140502095509.21732.16127.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sun, 18 May 2014 14:43:36 +0200 Message-ID: <043201cf7296$c9527940$5bf76bc0$@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: AQHPZeyd/cHap6Ml70mhGHdWVtbuyJstv0cAgBhTI5A= Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/O0uCPlFOg-qJOOau2fY5miD5X9I Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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: Sun, 18 May 2014 12:43:45 -0000 I browsed through this document and to me it looks mature enough to be=20 pushed forward (hopefully soon) to get an IANA anycast address etc., so=20 these things can be put into current WebRTC browsers. As we know, many=20 enterprises cannot use WebRTC at all today due to their restrictive=20 firewall policies - they need a TURN server on their LAN, discovered=20 and used by the WebRTC browsers to even begin using WebRTC. However, I raised a few questions and some suggestions=20 http://www.ietf.org/mail-archive/web/tram/current/msg00480.html=20 at the end of the previous version of this draft that never became=20 discussed and remain: A) Under 8.2 there is a suggested way to assure that the TURN server=20 returned by the anycast method, is provided by the network=20 provider (and not some far away TURN server that should not be trusted=20 to use without authentication): "... can set an IP TTL on their TURN=20 requests that limits how far they can travel into the public Internet." I suggest that this TTL limitation is specified (e.g. Don't look further = than 3 steps - local firewall + max 2 ISP routers) and brought into=20 section "5. Discovery using Anycast" of the draft. B) Shall we really have more than one method? If the Anycast method can=20 be used by everyone, why then also have DHCP and now a two more methods? I assume you intend that all webrtc browsers implement and can use all=20 methods? Or? (If a service provider e.g. deploys DHCP discovered TURN=20 servers, but some webrtc browser in some operating system don't=20 find/cannot use the TURN server, it would be bad.) In previous discussions, there were some fears that DHCP options are=20 not available in some common OSs. If so, I think the DHCP method should=20 be skipped.=20 Also, if the other methods (other than anycast) may fail, why have them? = Are they better to deploy and provision for network service providers? And will webrtc browsers implement all these methods? Do we have input/feedback on these questions? Should the "connect speed factor" not also be considered? Even though=20 the auto discovery can be done in advance of a call, we should consider=20 the mobility use case. With a mobile client changing network,=20 LAN/LTE/public WiFi etc., we want to get up and run as soon as possible, = so the auto discovery of a new TURN server should not be a tedious = process And should the quick anycast auto discovery not be the first to be=20 tried/used (which it is not now in the draft)? C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery=20 is now RFC7216. /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil = (praspati) Skickat: den 2 maj 2014 12:02 Till: tram@ietf.org =C4mne: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-01.txt A new revision of the TURN server discovery draft has been published. Notable updates : * 300 (Try Alternate) response for anycast. * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients = own address to populate the DNS reverse zone (i.e., in-addr.arpa or = ip6.arpa) with appropriate NAPTR records pointing to the TURN server. * Learning domain names from own identity. -Prashanth On 5/2/14 3:25 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >has been successfully submitted by Prashanth Patil and posted to the=20 >IETF repository. > >Name: draft-patil-tram-turn-serv-disc >Revision: 01 >Title: TURN Server Auto Discovery >Document date: 2014-05-02 >Group: Individual Submission >Pages: 11 >URL: =20 >http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01.t= xt >Status: =20 >https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >Htmlized: =20 >http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 > >Abstract: > Current Traversal Using Relays around NAT (TURN) server discovery > mechanisms are relatively static and limited to explicit > configuration. These are usually under the administrative control = of > the application or TURN service provider, and not the enterprise or > the ISP, the network in which the client is located. Enterprises = and > ISPs wishing to provide their own TURN servers need auto discovery > mechanisms that a TURN client could use with no or minimal > configuration. This document describes two such mechanisms for TURN > server discovery. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Mon May 19 01:47: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 D08371A0324 for ; Mon, 19 May 2014 01:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 W4IAoe-m7eMx for ; Mon, 19 May 2014 01:47:46 -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 4EAEB1A0323 for ; Mon, 19 May 2014 01:47:46 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8FC9F47533 for ; Mon, 19 May 2014 08:47:45 +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 37A324752D for ; Mon, 19 May 2014 08:47:45 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 339292026 for ; Mon, 19 May 2014 08:47:45 +0000 (GMT) Message-ID: <5379C531.6090202@akamai.com> Date: Mon, 19 May 2014 04:47:45 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140502095509.21732.16127.idtracker@ietfa.amsl.com> <043201cf7296$c9527940$5bf76bc0$@stahl@intertex.se> In-Reply-To: <043201cf7296$c9527940$5bf76bc0$@stahl@intertex.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-VN-WA5RbuhBoAlXccNjKl8yjS0 Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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: Mon, 19 May 2014 08:47:49 -0000 I'm not sure how realistic it is to define a specific TTL limitation. That assumes a perhaps unrealistic degree of uniformity in both the local network implementation and the ISP network implementation. Regarding whether multiple methods should be in the spec, one other important question to answer is whether all of the proposed methods have identical security properties. There were some security limitations for anycast (at least the well-known-address version) discussed on the list. These security limitations still need some discussion in the draft. Regarding connect time, in what way is the anycast method faster than name resolution? Under some conditions it may be faster, but typically it will require an extra round-trip between the client and the anycast address just as name resolution will require a round-trip between the client and the DNS server. --Brandon On 05/18/2014 08:43 AM, Karl Stahl wrote: > I browsed through this document and to me it looks mature enough to be > pushed forward (hopefully soon) to get an IANA anycast address etc., so > these things can be put into current WebRTC browsers. As we know, many > enterprises cannot use WebRTC at all today due to their restrictive > firewall policies - they need a TURN server on their LAN, discovered > and used by the WebRTC browsers to even begin using WebRTC. > > However, I raised a few questions and some suggestions > http://www.ietf.org/mail-archive/web/tram/current/msg00480.html > at the end of the previous version of this draft that never became > discussed and remain: > > A) Under 8.2 there is a suggested way to assure that the TURN server > returned by the anycast method, is provided by the network > provider (and not some far away TURN server that should not be trusted > to use without authentication): "... can set an IP TTL on their TURN > requests that limits how far they can travel into the public Internet." > > I suggest that this TTL limitation is specified (e.g. Don't look further > than 3 steps - local firewall + max 2 ISP routers) and brought into > section "5. Discovery using Anycast" of the draft. > > B) Shall we really have more than one method? If the Anycast method can > be used by everyone, why then also have DHCP and now a two more methods? > > I assume you intend that all webrtc browsers implement and can use all > methods? Or? (If a service provider e.g. deploys DHCP discovered TURN > servers, but some webrtc browser in some operating system don't > find/cannot use the TURN server, it would be bad.) > > In previous discussions, there were some fears that DHCP options are > not available in some common OSs. If so, I think the DHCP method should > be skipped. > > Also, if the other methods (other than anycast) may fail, why have them? > Are they better to deploy and provision for network service providers? > > And will webrtc browsers implement all these methods? > > Do we have input/feedback on these questions? > > Should the "connect speed factor" not also be considered? Even though > the auto discovery can be done in advance of a call, we should consider > the mobility use case. With a mobile client changing network, > LAN/LTE/public WiFi etc., we want to get up and run as soon as possible, > so the auto discovery of a new TURN server should not be a tedious process > > And should the quick anycast auto discovery not be the first to be > tried/used (which it is not now in the draft)? > > C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery > is now RFC7216. > > /Karl > > > -----Ursprungligt meddelande----- > Från: tram [mailto:tram-bounces@ietf.org] För Prashanth Patil (praspati) > Skickat: den 2 maj 2014 12:02 > Till: tram@ietf.org > Ämne: [tram] FW: New Version Notification for > draft-patil-tram-turn-serv-disc-01.txt > > A new revision of the TURN server discovery draft has been published. > Notable updates : > > * 300 (Try Alternate) response for anycast. > * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients own > address to populate the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa) > with appropriate NAPTR records pointing to the TURN server. > * Learning domain names from own identity. > > -Prashanth > > > On 5/2/14 3:25 PM, "internet-drafts@ietf.org" > wrote: > >> >> A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >> has been successfully submitted by Prashanth Patil and posted to the >> IETF repository. >> >> Name: draft-patil-tram-turn-serv-disc >> Revision: 01 >> Title: TURN Server Auto Discovery >> Document date: 2014-05-02 >> Group: Individual Submission >> Pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >> Htmlized: >> http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-patil-tram-turn-serv-disc-01 >> >> Abstract: >> Current Traversal Using Relays around NAT (TURN) server discovery >> mechanisms are relatively static and limited to explicit >> configuration. These are usually under the administrative control of >> the application or TURN service provider, and not the enterprise or >> the ISP, the network in which the client is located. Enterprises and >> ISPs wishing to provide their own TURN servers need auto discovery >> mechanisms that a TURN client could use with no or minimal >> configuration. This document describes two such mechanisms for TURN >> server discovery. >> >> >> >> >> >> 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 > > _______________________________________________ > 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 May 19 04:05: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 485AE1A035C for ; Mon, 19 May 2014 04:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] 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 uvHMuZ9qgkFe for ; Mon, 19 May 2014 04:05:27 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EB11A0354 for ; Mon, 19 May 2014 04:05:24 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201405191305215015; Mon, 19 May 2014 13:05:21 +0200 From: "Karl Stahl" To: "'Brandon Williams'" , References: <20140502095509.21732.16127.idtracker@ietfa.amsl.com> <043201cf7296$c9527940$5bf76bc0$@stahl@intertex.se> <5379C531.6090202@akamai.com> In-Reply-To: <5379C531.6090202@akamai.com> Date: Mon, 19 May 2014 13:05:19 +0200 Message-ID: <054701cf7352$393a0550$abae0ff0$@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: Ac9zPwdSXGvX9PNzSd+8O1X5lAgUzQADGPGA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PTi6TNA6hJyhR9gDydK2KASO_68 Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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: Mon, 19 May 2014 11:05:29 -0000 > require a round-trip between... - I wasn't concerned about round-trips, but rather possible time-outs = when there is nothing to find - I haven't really checked (concerned about = that we don't specify something slow creating a need to trickle or something) Regarding multiple methods and TTL limitation, is the intention of this draft that it may/could be used by rtcweb as: "... webrtc browsers MUST use turn servers discovered by the anycast = method in draft-patil-tram-turn-serv-disc-01.txt with TTL limitation set to = 3..." ? /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Brandon Williams Skickat: den 19 maj 2014 10:48 Till: tram@ietf.org =C4mne: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt I'm not sure how realistic it is to define a specific TTL limitation.=20 That assumes a perhaps unrealistic degree of uniformity in both the = local network implementation and the ISP network implementation. Regarding whether multiple methods should be in the spec, one other important question to answer is whether all of the proposed methods have identical security properties. There were some security limitations for anycast (at least the well-known-address version) discussed on the list. = These security limitations still need some discussion in the draft. Regarding connect time, in what way is the anycast method faster than = name resolution? Under some conditions it may be faster, but typically it = will require an extra round-trip between the client and the anycast address = just as name resolution will require a round-trip between the client and the = DNS server. --Brandon On 05/18/2014 08:43 AM, Karl Stahl wrote: > I browsed through this document and to me it looks mature enough to be = > pushed forward (hopefully soon) to get an IANA anycast address etc.,=20 > so these things can be put into current WebRTC browsers. As we know,=20 > many enterprises cannot use WebRTC at all today due to their=20 > restrictive firewall policies - they need a TURN server on their LAN,=20 > discovered and used by the WebRTC browsers to even begin using WebRTC. > > However, I raised a few questions and some suggestions=20 > http://www.ietf.org/mail-archive/web/tram/current/msg00480.html > at the end of the previous version of this draft that never became=20 > discussed and remain: > > A) Under 8.2 there is a suggested way to assure that the TURN server=20 > returned by the anycast method, is provided by the network provider=20 > (and not some far away TURN server that should not be trusted to use=20 > without authentication): "... can set an IP TTL on their TURN requests = > that limits how far they can travel into the public Internet." > > I suggest that this TTL limitation is specified (e.g. Don't look=20 > further than 3 steps - local firewall + max 2 ISP routers) and brought = > into section "5. Discovery using Anycast" of the draft. > > B) Shall we really have more than one method? If the Anycast method=20 > can be used by everyone, why then also have DHCP and now a two more methods? > > I assume you intend that all webrtc browsers implement and can use all = > methods? Or? (If a service provider e.g. deploys DHCP discovered TURN=20 > servers, but some webrtc browser in some operating system don't=20 > find/cannot use the TURN server, it would be bad.) > > In previous discussions, there were some fears that DHCP options are=20 > not available in some common OSs. If so, I think the DHCP method=20 > should be skipped. > > Also, if the other methods (other than anycast) may fail, why have = them? > Are they better to deploy and provision for network service providers? > > And will webrtc browsers implement all these methods? > > Do we have input/feedback on these questions? > > Should the "connect speed factor" not also be considered? Even though=20 > the auto discovery can be done in advance of a call, we should=20 > consider the mobility use case. With a mobile client changing network, = > LAN/LTE/public WiFi etc., we want to get up and run as soon as=20 > possible, so the auto discovery of a new TURN server should not be a=20 > tedious process > > And should the quick anycast auto discovery not be the first to be=20 > tried/used (which it is not now in the draft)? > > C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery > is now RFC7216. > > /Karl > > > -----Ursprungligt meddelande----- > Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil=20 > (praspati) > Skickat: den 2 maj 2014 12:02 > Till: tram@ietf.org > =C4mne: [tram] FW: New Version Notification for=20 > draft-patil-tram-turn-serv-disc-01.txt > > A new revision of the TURN server discovery draft has been published. > Notable updates : > > * 300 (Try Alternate) response for anycast. > * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients = > own address to populate the DNS reverse zone (i.e., in-addr.arpa or=20 > ip6.arpa) with appropriate NAPTR records pointing to the TURN server. > * Learning domain names from own identity. > > -Prashanth > > > On 5/2/14 3:25 PM, "internet-drafts@ietf.org"=20 > > wrote: > >> >> A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >> has been successfully submitted by Prashanth Patil and posted to the=20 >> IETF repository. >> >> Name: draft-patil-tram-turn-serv-disc >> Revision: 01 >> Title: TURN Server Auto Discovery >> Document date: 2014-05-02 >> Group: Individual Submission >> Pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-0 >> 1.txt >> Status: >> https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >> Htmlized: >> http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 >> >> Abstract: >> Current Traversal Using Relays around NAT (TURN) server discovery >> mechanisms are relatively static and limited to explicit >> configuration. These are usually under the administrative control = of >> the application or TURN service provider, and not the enterprise = or >> the ISP, the network in which the client is located. Enterprises = and >> ISPs wishing to provide their own TURN servers need auto discovery >> mechanisms that a TURN client could use with no or minimal >> configuration. This document describes two such mechanisms for = TURN >> server discovery. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > 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. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Mon May 19 05:15: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 C0EB21A0352 for ; Mon, 19 May 2014 05:15: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 Vn6uAsn3i-kI for ; Mon, 19 May 2014 05:15:30 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C3F1A0365 for ; Mon, 19 May 2014 05:15:29 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rl12so2111387iec.23 for ; Mon, 19 May 2014 05:15:29 -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=SAQIiQ8pkq1yX60HbdL+gKpCU6Tp440sEFs4vspsMpk=; b=h3QFB9pi311TsDA6mQn41EjyLIdq/SGAzWkm7WZCWxUCdQcLSF4J69vhPDTeVTvVNV lujlgUNaxHpjN9lysgAatW1nkwwPT/7cqnpRnkyUGIemvOhfgjEMWK4bvB7PZWPFsKO+ hzOTMiA/1o3PcdS1mGiDE0AGXcX2CwQFipSy8= 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=SAQIiQ8pkq1yX60HbdL+gKpCU6Tp440sEFs4vspsMpk=; b=izf0KtZrO1ITXwBjh5Ajj5AoOBtd8kANwkVue4Vt/DOp5utNr6/JemF/8efBI1DuPd R65PoOLOSNiygsbhXcXFw4LbI+KrTBtTRz+B2ttPxi8IJ7ZVzNO/IqPxHp1VmnA6y1QT N3jbTRD/O2aV6qyK+sfaJU8BXAWhbSisKSUHVPCu2rwqXOaIGxbMVLpUW4Ou5JCAxfmN 3NQSf7aMw0FDXA3XFsexoFWty3ZyUGf/JCZ9Q4xnSBpCjdsgpnHlMWDyGGB0zkhBrTR5 NgVI89E75NhiWdH6azk9WhI3nfY1RspNL92hOtEC7zZF0okXuyvR1L4VBZZkCjjmAAK4 G+8w== X-Gm-Message-State: ALoCoQnAOFLCxXp9CPFf1l0KLi2naKxPsAwE8sI2cfgyNy49qlsRlsccv3O1QfS1GrZwuj35Fqtw X-Received: by 10.42.98.145 with SMTP id s17mr2007919icn.73.1400501729493; Mon, 19 May 2014 05:15:29 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id kw1sm20636148igb.4.2014.05.19.05.15.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 05:15:28 -0700 (PDT) Message-ID: <5379F5DA.9020709@getjive.com> Date: Mon, 19 May 2014 06:15:22 -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: "tram@ietf.org" References: <20140519092035.13867.6342.idtracker@ietfa.amsl.com> In-Reply-To: <20140519092035.13867.6342.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140519092035.13867.6342.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="usiE14GwvpQngGgssVkv044t8GanDPkGO" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Isti74Xk9OFHMt-NctwZV_DgPww Subject: [tram] Fwd: I-D Action: draft-petithuguenin-tram-stun-dane-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, 19 May 2014 12:15:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --usiE14GwvpQngGgssVkv044t8GanDPkGO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is the draft that explains how to use DANE with STUN over TLS or DTL= S. With this draft and the ALPN draft, I think that we now covered everything that was discussed in London about STUN over DTLS. -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-tram-stun-dane-00.txt Date: Mon, 19 May 2014 02:20:35 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using DNS-based Authentication of Named Entities (DANE) to validate TLS certificates for the Session Traversal Utilities for NAT (STUN) protocol Authors : Marc Petit-Huguenin Olle E. Johansson Gonzalo Salgueiro Filename : draft-petithuguenin-tram-stun-dane-00.txt Pages : 6 Date : 2014-05-19 Abstract: This document defines how DNS-based Authentication of Named Entities (DANE) can be used to validate TLS certificates with the Session Traversal Utilities for NAT (STUN) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-petithuguenin-tram-stun-dane/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-petithuguenin-tram-stun-dane-00 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --usiE14GwvpQngGgssVkv044t8GanDPkGO 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/ iQEcBAEBAgAGBQJTefXfAAoJEMUNRP98lsiX7MMH/2HntjWaCaxCngNHlrfULyeu yV+IE+ZAemQF6nFjeQS0LWPa4zLdIJVJbFsR7LLyzuwItcU9rCApYXZmOlhkHjI1 U8prQrgxmDCKHCm1FO2K7cgrsLAa3H3AlE2NTibNFhp19T/LwtCUGF78GRAlUc+B Pn+Z2RY5RWesXpMh8WmLEcjDCWtIZd68DO65j/GhYFtBty/fZKHUzS/w29yCwFvD liiwMqRB9SjkrejbGegZwIza4PSimR1RSGWTfuQplM4fA1GU5LUVJikjwugDlZ+a ZFLSIdvOn0mmxcM+i3TjXAQzPmQ+2MPsGRNxuAEmIHwhw/5QIh7NuJq/VRCNPYo= =LdUM -----END PGP SIGNATURE----- --usiE14GwvpQngGgssVkv044t8GanDPkGO-- From nobody Mon May 19 05:22:40 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 AD9CC1A036E for ; Mon, 19 May 2014 05:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 3RZErTUoAwH1 for ; Mon, 19 May 2014 05:22:36 -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 380A01A0249 for ; Mon, 19 May 2014 05:22:29 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F296447540; Mon, 19 May 2014 12:22:28 +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 E5EBF474D4; Mon, 19 May 2014 12:22:28 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id E26882026; Mon, 19 May 2014 12:22:28 +0000 (GMT) Message-ID: <5379F784.1000606@akamai.com> Date: Mon, 19 May 2014 08:22:28 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Karl Stahl , "tram@ietf.org" References: <20140502095509.21732.16127.idtracker@ietfa.amsl.com> <043201cf7296$c9527940$5bf76bc0$@stahl@intertex.se> <5379C531.6090202@akamai.com> <054701cf7352$393a0550$abae0ff0$@stahl@intertex.se> In-Reply-To: <054701cf7352$393a0550$abae0ff0$@stahl@intertex.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RkbpBrYmBZePS9eue695L4UHfgg Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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: Mon, 19 May 2014 12:22:38 -0000 I would be more concerned about anycast timing out than DNS. If the dns server exists but has no answer, it will tell you. I think you would only need a timeout for non-existent DNS servers. On the other hand, the only way you know that the anycast address doesn't work is a timeout waiting for a response. You could use an ICMP ttl-exceeded response, but they aren't reliably sent or delivered. I would argue strongly against MUST for supporting anycast, because of the security issues that have been raised. I would say SHOULD support, and those that do MUST allow users to define security policies that prohibit using anycast. --Brandon On 05/19/2014 07:05 AM, Karl Stahl wrote: >> require a round-trip between... > - I wasn't concerned about round-trips, but rather possible time-outs when > there is nothing to find - I haven't really checked (concerned about that we > don't specify something slow creating a need to trickle or something) > > Regarding multiple methods and TTL limitation, is the intention of this > draft that it may/could be used by rtcweb as: > "... webrtc browsers MUST use turn servers discovered by the anycast method > in draft-patil-tram-turn-serv-disc-01.txt with TTL limitation set to 3..." ? > > /Karl > > > -----Ursprungligt meddelande----- > Från: tram [mailto:tram-bounces@ietf.org] För Brandon Williams > Skickat: den 19 maj 2014 10:48 > Till: tram@ietf.org > Ämne: Re: [tram] New Version Notification for > draft-patil-tram-turn-serv-disc-01.txt > > I'm not sure how realistic it is to define a specific TTL limitation. > That assumes a perhaps unrealistic degree of uniformity in both the local > network implementation and the ISP network implementation. > > Regarding whether multiple methods should be in the spec, one other > important question to answer is whether all of the proposed methods have > identical security properties. There were some security limitations for > anycast (at least the well-known-address version) discussed on the list. > These security limitations still need some discussion in the draft. > > Regarding connect time, in what way is the anycast method faster than name > resolution? Under some conditions it may be faster, but typically it will > require an extra round-trip between the client and the anycast address just > as name resolution will require a round-trip between the client and the DNS > server. > > --Brandon > > On 05/18/2014 08:43 AM, Karl Stahl wrote: >> I browsed through this document and to me it looks mature enough to be >> pushed forward (hopefully soon) to get an IANA anycast address etc., >> so these things can be put into current WebRTC browsers. As we know, >> many enterprises cannot use WebRTC at all today due to their >> restrictive firewall policies - they need a TURN server on their LAN, >> discovered and used by the WebRTC browsers to even begin using WebRTC. >> >> However, I raised a few questions and some suggestions >> http://www.ietf.org/mail-archive/web/tram/current/msg00480.html >> at the end of the previous version of this draft that never became >> discussed and remain: >> >> A) Under 8.2 there is a suggested way to assure that the TURN server >> returned by the anycast method, is provided by the network provider >> (and not some far away TURN server that should not be trusted to use >> without authentication): "... can set an IP TTL on their TURN requests >> that limits how far they can travel into the public Internet." >> >> I suggest that this TTL limitation is specified (e.g. Don't look >> further than 3 steps - local firewall + max 2 ISP routers) and brought >> into section "5. Discovery using Anycast" of the draft. >> >> B) Shall we really have more than one method? If the Anycast method >> can be used by everyone, why then also have DHCP and now a two more > methods? >> >> I assume you intend that all webrtc browsers implement and can use all >> methods? Or? (If a service provider e.g. deploys DHCP discovered TURN >> servers, but some webrtc browser in some operating system don't >> find/cannot use the TURN server, it would be bad.) >> >> In previous discussions, there were some fears that DHCP options are >> not available in some common OSs. If so, I think the DHCP method >> should be skipped. >> >> Also, if the other methods (other than anycast) may fail, why have them? >> Are they better to deploy and provision for network service providers? >> >> And will webrtc browsers implement all these methods? >> >> Do we have input/feedback on these questions? >> >> Should the "connect speed factor" not also be considered? Even though >> the auto discovery can be done in advance of a call, we should >> consider the mobility use case. With a mobile client changing network, >> LAN/LTE/public WiFi etc., we want to get up and run as soon as >> possible, so the auto discovery of a new TURN server should not be a >> tedious process >> >> And should the quick anycast auto discovery not be the first to be >> tried/used (which it is not now in the draft)? >> >> C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery >> is now RFC7216. >> >> /Karl >> >> >> -----Ursprungligt meddelande----- >> Från: tram [mailto:tram-bounces@ietf.org] För Prashanth Patil >> (praspati) >> Skickat: den 2 maj 2014 12:02 >> Till: tram@ietf.org >> Ämne: [tram] FW: New Version Notification for >> draft-patil-tram-turn-serv-disc-01.txt >> >> A new revision of the TURN server discovery draft has been published. >> Notable updates : >> >> * 300 (Try Alternate) response for anycast. >> * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients >> own address to populate the DNS reverse zone (i.e., in-addr.arpa or >> ip6.arpa) with appropriate NAPTR records pointing to the TURN server. >> * Learning domain names from own identity. >> >> -Prashanth >> >> >> On 5/2/14 3:25 PM, "internet-drafts@ietf.org" >> >> wrote: >> >>> >>> A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >>> has been successfully submitted by Prashanth Patil and posted to the >>> IETF repository. >>> >>> Name: draft-patil-tram-turn-serv-disc >>> Revision: 01 >>> Title: TURN Server Auto Discovery >>> Document date: 2014-05-02 >>> Group: Individual Submission >>> Pages: 11 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-0 >>> 1.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-patil-tram-turn-serv-disc-01 >>> >>> Abstract: >>> Current Traversal Using Relays around NAT (TURN) server discovery >>> mechanisms are relatively static and limited to explicit >>> configuration. These are usually under the administrative control of >>> the application or TURN service provider, and not the enterprise or >>> the ISP, the network in which the client is located. Enterprises and >>> ISPs wishing to provide their own TURN servers need auto discovery >>> mechanisms that a TURN client could use with no or minimal >>> configuration. This document describes two such mechanisms for TURN >>> server discovery. >>> >>> >>> >>> >>> >>> 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 >> >> _______________________________________________ >> 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 Mon May 19 11:11: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 6791F1A03B6 for ; Mon, 19 May 2014 11:11:45 -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 CksReEw5XBl7 for ; Mon, 19 May 2014 11:11:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F371A03B8 for ; Mon, 19 May 2014 11:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6072; q=dns/txt; s=iport; t=1400523102; x=1401732702; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=COzZo9bVWhERpGm9R6WvvSQGbE6nwlLQKYIfH3T5P1I=; b=O0aZxlfjzcR4L2riaTig7KmyVBMe3/qkDtzAVRi6RFhHRC0ukLtFy1xA hgNDw0v1Rw915/A6mkPVBtXtg9i72ekIiWUucMW0G1FtX9zq8adXAN0Oi +TQtC5uXDAwx+Nk07e5AYb0svuipzg+ENSsvexWwod+l+46LP6UQ8DsJe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0MAB5IelOtJA2K/2dsb2JhbABQCYMGUVEHqVEBAQEBAQEFAZJuhz2BFxZ0gicBBAEBAWoBCRQBCD8uCxQTBAESCYg4CAXSIBeFVYNchEQDBwEBHDWERQSJW49/gT2RXYF3gUBtgQEJFyI X-IronPort-AV: E=Sophos;i="4.98,868,1392163200"; d="scan'208";a="326198045" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 19 May 2014 18:11:41 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4JIBfGp009088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 May 2014 18:11:41 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.7]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 19 May 2014 13:11:41 -0500 From: "Prashanth Patil (praspati)" To: Karl Stahl , "tram@ietf.org" , "'Simon Perreault'" Thread-Topic: SV: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt Thread-Index: AQHPc43IbOJT0vrVWEG2+B+Z3BZJRQ== Date: Mon, 19 May 2014 18:11:40 +0000 Message-ID: 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: [10.65.39.213] 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/qA__runRhul8SdayYPyliWYcet0 Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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: Mon, 19 May 2014 18:11:45 -0000 Hi Karl, On 5/18/14 6:13 PM, "Karl Stahl" wrote: >I browsed through this document and to me it looks mature enough to be >pushed forward (hopefully soon) to get an IANA anycast address etc., so >these things can be put into current WebRTC browsers. As we know, many >enterprises cannot use WebRTC at all today due to their restrictive >firewall policies - they need a TURN server on their LAN, discovered >and used by the WebRTC browsers to even begin using WebRTC. > >However, I raised a few questions and some suggestions >http://www.ietf.org/mail-archive/web/tram/current/msg00480.html >at the end of the previous version of this draft that never became >discussed and remain: > >A) Under 8.2 there is a suggested way to assure that the TURN server >returned by the anycast method, is provided by the network >provider (and not some far away TURN server that should not be trusted >to use without authentication): "... can set an IP TTL on their TURN >requests that limits how far they can travel into the public Internet." > >I suggest that this TTL limitation is specified (e.g. Don't look further >than 3 steps - local firewall + max 2 ISP routers) and brought into >section "5. Discovery using Anycast" of the draft. I think the decision should be left up to the application. We could, maybe, make a recommendation at best (i.e. it is not a MUST). > >B) Shall we really have more than one method? If the Anycast method can >be used by everyone, why then also have DHCP and now a two more methods? There are essentially 2 methods described in the draft (1) Service resolution and (2) Anycast. We'll probably need both if we want to maximize chances of discovery. DHCP happens to be one method to obtain the domain-name for (1) Service resolution. While the DHCP method may not workable in some cases, the other two methods (one of them inspired by draft-kist-alto-3pdisc) could offer better results. We can do away with DHCP, if that is the WG consensus. > >I assume you intend that all webrtc browsers implement and can use all >methods? Or? (If a service provider e.g. deploys DHCP discovered TURN >servers, but some webrtc browser in some operating system don't >find/cannot use the TURN server, it would be bad.) > >In previous discussions, there were some fears that DHCP options are >not available in some common OSs. If so, I think the DHCP method should >be skipped.=20 > >Also, if the other methods (other than anycast) may fail, why have them? Anycast may fail, too. >=20 >Are they better to deploy and provision for network service providers? > >And will webrtc browsers implement all these methods? > >Do we have input/feedback on these questions? > >Should the "connect speed factor" not also be considered? Even though >the auto discovery can be done in advance of a call, we should consider >the mobility use case. With a mobile client changing network, >LAN/LTE/public WiFi etc., we want to get up and run as soon as possible, >so the auto discovery of a new TURN server should not be a tedious process > >And should the quick anycast auto discovery not be the first to be >tried/used (which it is not now in the draft)? Given that there is a service resolution mechanism for TURN over DTLS (http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it seems useful to do service resolution before. > >C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery >is now RFC7216. Thanks, will update. -Prashanth > >/Karl > > >-----Ursprungligt meddelande----- >Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil (praspat= i) >Skickat: den 2 maj 2014 12:02 >Till: tram@ietf.org >=C4mne: [tram] FW: New Version Notification for >draft-patil-tram-turn-serv-disc-01.txt > >A new revision of the TURN server discovery draft has been published. >Notable updates : > >* 300 (Try Alternate) response for anycast. >* Mechanism described in draft-kist-alto-3pdisc i.e. using the clients own >address to populate the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa) >with appropriate NAPTR records pointing to the TURN server. >* Learning domain names from own identity. > >-Prashanth > > >On 5/2/14 3:25 PM, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >>has been successfully submitted by Prashanth Patil and posted to the >>IETF repository. >> >>Name: draft-patil-tram-turn-serv-disc >>Revision: 01 >>Title: TURN Server Auto Discovery >>Document date: 2014-05-02 >>Group: Individual Submission >>Pages: 11 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01.tx >>t >>Status: =20 >>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >>Htmlized: =20 >>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 >> >>Abstract: >> Current Traversal Using Relays around NAT (TURN) server discovery >> mechanisms are relatively static and limited to explicit >> configuration. These are usually under the administrative control of >> the application or TURN service provider, and not the enterprise or >> the ISP, the network in which the client is located. Enterprises and >> ISPs wishing to provide their own TURN servers need auto discovery >> mechanisms that a TURN client could use with no or minimal >> configuration. This document describes two such mechanisms for TURN >> server discovery. >> >> =20 >> =20 >> >> >>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 > From nobody Mon May 19 15:28: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 DAF9B1A01BD for ; Mon, 19 May 2014 15:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] 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 5Qbfzt8s5dP2 for ; Mon, 19 May 2014 15:28:02 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B891A1A0195 for ; Mon, 19 May 2014 15:28:00 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201405200027572747; Tue, 20 May 2014 00:27:57 +0200 From: "Karl Stahl" To: "'Prashanth Patil \(praspati\)'" , , "'Simon Perreault'" References: In-Reply-To: Date: Tue, 20 May 2014 00:27:55 +0200 Message-ID: <069201cf73b1$948b5a80$bda20f80$@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: AQHPc43IbOJT0vrVWEG2+B+Z3BZJRZtIej/g Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZOL5z2e8nBw3p3Bl60J-wFeiBhE Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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: Mon, 19 May 2014 22:28:05 -0000 I read "We'll probably need both if we want to maximize chances of discovery." in the draft also, but don't really get it. Do you mean that if the network provider offers one particular TURN = server to his network users, that TURN server should be advertised in both suggested ways? /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil = (praspati) Skickat: den 19 maj 2014 20:12 Till: Karl Stahl; tram@ietf.org; 'Simon Perreault' =C4mne: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt Hi Karl, On 5/18/14 6:13 PM, "Karl Stahl" wrote: >I browsed through this document and to me it looks mature enough to be=20 >pushed forward (hopefully soon) to get an IANA anycast address etc., so = >these things can be put into current WebRTC browsers. As we know, many=20 >enterprises cannot use WebRTC at all today due to their restrictive=20 >firewall policies - they need a TURN server on their LAN, discovered=20 >and used by the WebRTC browsers to even begin using WebRTC. > >However, I raised a few questions and some suggestions=20 >http://www.ietf.org/mail-archive/web/tram/current/msg00480.html >at the end of the previous version of this draft that never became=20 >discussed and remain: > >A) Under 8.2 there is a suggested way to assure that the TURN server=20 >returned by the anycast method, is provided by the network provider=20 >(and not some far away TURN server that should not be trusted to use=20 >without authentication): "... can set an IP TTL on their TURN requests=20 >that limits how far they can travel into the public Internet." > >I suggest that this TTL limitation is specified (e.g. Don't look=20 >further than 3 steps - local firewall + max 2 ISP routers) and brought=20 >into section "5. Discovery using Anycast" of the draft. I think the decision should be left up to the application. We could, = maybe, make a recommendation at best (i.e. it is not a MUST). > >B) Shall we really have more than one method? If the Anycast method can = >be used by everyone, why then also have DHCP and now a two more = methods? There are essentially 2 methods described in the draft (1) Service resolution and (2) Anycast. We'll probably need both if we want to = maximize chances of discovery. DHCP happens to be one method to obtain the domain-name for (1) Service resolution. While the DHCP method may not workable in some cases, the = other two methods (one of them inspired by draft-kist-alto-3pdisc) could offer better results. We can do away with DHCP, if that is the WG consensus. > >I assume you intend that all webrtc browsers implement and can use all=20 >methods? Or? (If a service provider e.g. deploys DHCP discovered TURN=20 >servers, but some webrtc browser in some operating system don't=20 >find/cannot use the TURN server, it would be bad.) > >In previous discussions, there were some fears that DHCP options are=20 >not available in some common OSs. If so, I think the DHCP method should = >be skipped. > >Also, if the other methods (other than anycast) may fail, why have = them? Anycast may fail, too. >=20 >Are they better to deploy and provision for network service providers? > >And will webrtc browsers implement all these methods? > >Do we have input/feedback on these questions? > >Should the "connect speed factor" not also be considered? Even though=20 >the auto discovery can be done in advance of a call, we should consider = >the mobility use case. With a mobile client changing network,=20 >LAN/LTE/public WiFi etc., we want to get up and run as soon as=20 >possible, so the auto discovery of a new TURN server should not be a=20 >tedious process > >And should the quick anycast auto discovery not be the first to be=20 >tried/used (which it is not now in the draft)? Given that there is a service resolution mechanism for TURN over DTLS (http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it = seems useful to do service resolution before. > >C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery >is now RFC7216. Thanks, will update. -Prashanth > >/Karl > > >-----Ursprungligt meddelande----- >Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil=20 >(praspati) >Skickat: den 2 maj 2014 12:02 >Till: tram@ietf.org >=C4mne: [tram] FW: New Version Notification for=20 >draft-patil-tram-turn-serv-disc-01.txt > >A new revision of the TURN server discovery draft has been published. >Notable updates : > >* 300 (Try Alternate) response for anycast. >* Mechanism described in draft-kist-alto-3pdisc i.e. using the clients=20 >own address to populate the DNS reverse zone (i.e., in-addr.arpa or=20 >ip6.arpa) with appropriate NAPTR records pointing to the TURN server. >* Learning domain names from own identity. > >-Prashanth > > >On 5/2/14 3:25 PM, "internet-drafts@ietf.org"=20 > >wrote: > >> >>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >>has been successfully submitted by Prashanth Patil and posted to the=20 >>IETF repository. >> >>Name: draft-patil-tram-turn-serv-disc >>Revision: 01 >>Title: TURN Server Auto Discovery >>Document date: 2014-05-02 >>Group: Individual Submission >>Pages: 11 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01 >>.tx >>t >>Status: =20 >>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >>Htmlized: =20 >>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 >> >>Abstract: >> Current Traversal Using Relays around NAT (TURN) server discovery >> mechanisms are relatively static and limited to explicit >> configuration. These are usually under the administrative control = of >> the application or TURN service provider, and not the enterprise or >> the ISP, the network in which the client is located. Enterprises = and >> ISPs wishing to provide their own TURN servers need auto discovery >> mechanisms that a TURN client could use with no or minimal >> configuration. This document describes two such mechanisms for = TURN >> server discovery. >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>The IETF Secretariat >> > >_______________________________________________ >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 May 20 00:14: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 4B8331A045D for ; Tue, 20 May 2014 00:14:34 -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 98nJcpsO5ihm for ; Tue, 20 May 2014 00:14:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E9D1A0035 for ; Tue, 20 May 2014 00:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7950; q=dns/txt; s=iport; t=1400570069; x=1401779669; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=d/ZSXiMY4WU7QY4Tyzol6JoRW8STC0ZWNx/aS8h7cnM=; b=EwPeLeagJMvdT3QxYc2Sk8hTLkJIMiV7nJOhO5R5aPg8ok2aMl7i5/DU Qhgh8iGJhZ/y+IEsfCOAekb1ObzgnPRyXdEiJZ7oLowDn3TX/+dOk+gRH kvBhnDuFSDG97ZH0lb4LoZDa4YdCvNk2hqmelZqNpolqPQ5YfZR1WVtO3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0IAEUAe1OtJA2D/2dsb2JhbABQCYMGUVEHvFaHOwGBFxZ0giUBAQEDAQEBAWoBCQ4EAgEIEQQBAQEKHQcnCxQJCAIEARIIAYgwCAgF0lgXiTCEQwMHAQEeMwUGgyWBFQSJYJE9kWCDOG2BAQkXIg X-IronPort-AV: E=Sophos;i="4.98,872,1392163200"; d="scan'208";a="326282134" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP; 20 May 2014 07:14:28 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4K7EStX010271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 May 2014 07:14:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 20 May 2014 02:14:27 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Karl Stahl , "Prashanth Patil (praspati)" , "tram@ietf.org" , "'Simon Perreault'" Thread-Topic: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt Thread-Index: AQHPc43INN+P5dH8gUSyAQOmv2KoiJtIz96AgAA+0DA= Date: Tue, 20 May 2014 07:14:27 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24335B49@xmb-rcd-x10.cisco.com> References: <069201cf73b1$948b5a80$bda20f80$@stahl@intertex.se> In-Reply-To: <069201cf73b1$948b5a80$bda20f80$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.51.197] 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/egf-KF1kMcPgQHt1CBPyUe6GFp4 Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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, 20 May 2014 07:14:35 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > Sent: Tuesday, May 20, 2014 3:58 AM > To: Prashanth Patil (praspati); tram@ietf.org; 'Simon Perreault' > Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-se= rv-disc- > 01.txt >=20 > I read "We'll probably need both if we want to maximize chances of > discovery." in the draft also, but don't really get it. With Secure DHCPv6 with Public Key http://tools.ietf.org/html/draft-ietf-dh= c-sedhcpv6-02, DHCP has benefits over Anycast. But since DHCP is not workable in some cases, clients may end-up using both= the techniques (for e.g. use happy-eyeball mechanism) and give precedence = to TURN server learnt using secure DHCP. >=20 > Do you mean that if the network provider offers one particular TURN serve= r > to his network users, that TURN server should be advertised in both > suggested ways? Yes -Tiru >=20 > /Karl >=20 > -----Ursprungligt meddelande----- > Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil (praspa= ti) > Skickat: den 19 maj 2014 20:12 > Till: Karl Stahl; tram@ietf.org; 'Simon Perreault' > =C4mne: Re: [tram] New Version Notification for > draft-patil-tram-turn-serv-disc-01.txt >=20 > Hi Karl, >=20 > On 5/18/14 6:13 PM, "Karl Stahl" wrote: >=20 > >I browsed through this document and to me it looks mature enough to be > >pushed forward (hopefully soon) to get an IANA anycast address etc., so > >these things can be put into current WebRTC browsers. As we know, many > >enterprises cannot use WebRTC at all today due to their restrictive > >firewall policies - they need a TURN server on their LAN, discovered > >and used by the WebRTC browsers to even begin using WebRTC. > > > >However, I raised a few questions and some suggestions > >http://www.ietf.org/mail-archive/web/tram/current/msg00480.html > >at the end of the previous version of this draft that never became > >discussed and remain: > > > >A) Under 8.2 there is a suggested way to assure that the TURN server > >returned by the anycast method, is provided by the network provider > >(and not some far away TURN server that should not be trusted to use > >without authentication): "... can set an IP TTL on their TURN requests > >that limits how far they can travel into the public Internet." > > > >I suggest that this TTL limitation is specified (e.g. Don't look > >further than 3 steps - local firewall + max 2 ISP routers) and brought > >into section "5. Discovery using Anycast" of the draft. >=20 > I think the decision should be left up to the application. We could, mayb= e, > make a recommendation at best (i.e. it is not a MUST). >=20 >=20 > > > >B) Shall we really have more than one method? If the Anycast method can > >be used by everyone, why then also have DHCP and now a two more methods? >=20 > There are essentially 2 methods described in the draft (1) Service > resolution and (2) Anycast. We'll probably need both if we want to maximi= ze > chances of discovery. > DHCP happens to be one method to obtain the domain-name for (1) Service > resolution. While the DHCP method may not workable in some cases, the oth= er > two methods (one of them inspired by draft-kist-alto-3pdisc) could offer > better results. We can do away with DHCP, if that is the WG consensus. >=20 >=20 > > > >I assume you intend that all webrtc browsers implement and can use all > >methods? Or? (If a service provider e.g. deploys DHCP discovered TURN > >servers, but some webrtc browser in some operating system don't > >find/cannot use the TURN server, it would be bad.) > > > >In previous discussions, there were some fears that DHCP options are > >not available in some common OSs. If so, I think the DHCP method should > >be skipped. > > > >Also, if the other methods (other than anycast) may fail, why have them? >=20 > Anycast may fail, too. >=20 >=20 > > > >Are they better to deploy and provision for network service providers? > > > >And will webrtc browsers implement all these methods? > > > >Do we have input/feedback on these questions? > > > >Should the "connect speed factor" not also be considered? Even though > >the auto discovery can be done in advance of a call, we should consider > >the mobility use case. With a mobile client changing network, > >LAN/LTE/public WiFi etc., we want to get up and run as soon as > >possible, so the auto discovery of a new TURN server should not be a > >tedious process > > > >And should the quick anycast auto discovery not be the first to be > >tried/used (which it is not now in the draft)? >=20 > Given that there is a service resolution mechanism for TURN over DTLS > (http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it seem= s > useful to do service resolution before. >=20 > > > >C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery > >is now RFC7216. >=20 > Thanks, will update. >=20 > -Prashanth >=20 >=20 > > > >/Karl > > > > > >-----Ursprungligt meddelande----- > >Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil > >(praspati) > >Skickat: den 2 maj 2014 12:02 > >Till: tram@ietf.org > >=C4mne: [tram] FW: New Version Notification for > >draft-patil-tram-turn-serv-disc-01.txt > > > >A new revision of the TURN server discovery draft has been published. > >Notable updates : > > > >* 300 (Try Alternate) response for anycast. > >* Mechanism described in draft-kist-alto-3pdisc i.e. using the clients > >own address to populate the DNS reverse zone (i.e., in-addr.arpa or > >ip6.arpa) with appropriate NAPTR records pointing to the TURN server. > >* Learning domain names from own identity. > > > >-Prashanth > > > > > >On 5/2/14 3:25 PM, "internet-drafts@ietf.org" > > > >wrote: > > > >> > >>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt > >>has been successfully submitted by Prashanth Patil and posted to the > >>IETF repository. > >> > >>Name: draft-patil-tram-turn-serv-disc > >>Revision: 01 > >>Title: TURN Server Auto Discovery > >>Document date: 2014-05-02 > >>Group: Individual Submission > >>Pages: 11 > >>URL: > >>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01 > >>.tx > >>t > >>Status: > >>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ > >>Htmlized: > >>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 > >>Diff: > >>http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 > >> > >>Abstract: > >> Current Traversal Using Relays around NAT (TURN) server discovery > >> mechanisms are relatively static and limited to explicit > >> configuration. These are usually under the administrative control o= f > >> the application or TURN service provider, and not the enterprise or > >> the ISP, the network in which the client is located. Enterprises an= d > >> ISPs wishing to provide their own TURN servers need auto discovery > >> mechanisms that a TURN client could use with no or minimal > >> configuration. This document describes two such mechanisms for TURN > >> server discovery. > >> > >> > >> > >> > >> > >>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 > > >=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 May 20 02:40:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D281A04C8 for ; Tue, 20 May 2014 02:40:29 -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 xNQFWk6NJxfu for ; Tue, 20 May 2014 02:40:27 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2497D1A05C3 for ; Tue, 20 May 2014 02:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7474; q=dns/txt; s=iport; t=1400578826; x=1401788426; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XCp/FlRdmBGx1lJfhtXvNNpMtoyLrk316mq7Gmm6FIE=; b=lR8NflABK5ARdrMxyliUmH5C2/cyHZcqAo0nwuauaHqALi6NZXGPidxA Tvj6dmaoCHO72VXZI+o1eti75ZYcdXMO05k01uhL0Qu11G/V64caWtbOm Mkv9MeoTK/4GOPz/lwVX0xD67eti0MVg8wZUamKgk51lDbi/Zxv7WMPZC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0NADoie1OtJV2T/2dsb2JhbABQCYMGUVEHqV4BAQEFAZJuhzsBgRkWdIIlAQEBBAEBAWoBCRICAQgYJwcnCxQRAgQTCYg4CAXSPheFVYNbhEMDBwEBHDUFhEAEiWCQAIE9kWCDOG2BAQkXIg X-IronPort-AV: E=Sophos;i="4.98,873,1392163200"; d="scan'208";a="45422432" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 20 May 2014 09:40:22 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s4K9eMCh011566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 May 2014 09:40:22 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.7]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 20 May 2014 04:40:22 -0500 From: "Prashanth Patil (praspati)" To: "tram@ietf.org" Thread-Topic: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt Thread-Index: AQHPc43I/cHap6Ml70mhGHdWVtbuyJtIej/ggAFtsIA= Date: Tue, 20 May 2014 09:40:21 +0000 Message-ID: References: <069201cf73b1$948b5a80$bda20f80$@stahl@intertex.se> In-Reply-To: <069201cf73b1$948b5a80$bda20f80$@stahl@intertex.se> 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: [10.142.189.176] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9A88F96F7E8238448A0B0501751A60CF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pvGFJBbzh4x-rG0OpZTsu8XvZUs Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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, 20 May 2014 09:40:29 -0000 On 5/20/14 3:57 AM, "Karl Stahl" wrote: >I read "We'll probably need both if we want to maximize chances of >discovery." in the draft also, but don't really get it. > >Do you mean that if the network provider offers one particular TURN server >to his network users, that TURN server should be advertised in both >suggested ways? By maximize, the draft really means discovering servers that may not support all discoverable methods. For example, if a provider already has TURN application service provisioned in DNS (as in RFC5928), it can be readily discovered without needing anycast. -Prashanth =20 > >/Karl > >-----Ursprungligt meddelande----- >Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil (praspat= i) >Skickat: den 19 maj 2014 20:12 >Till: Karl Stahl; tram@ietf.org; 'Simon Perreault' >=C4mne: Re: [tram] New Version Notification for >draft-patil-tram-turn-serv-disc-01.txt > >Hi Karl, > >On 5/18/14 6:13 PM, "Karl Stahl" wrote: > >>I browsed through this document and to me it looks mature enough to be >>pushed forward (hopefully soon) to get an IANA anycast address etc., so >>these things can be put into current WebRTC browsers. As we know, many >>enterprises cannot use WebRTC at all today due to their restrictive >>firewall policies - they need a TURN server on their LAN, discovered >>and used by the WebRTC browsers to even begin using WebRTC. >> >>However, I raised a few questions and some suggestions >>http://www.ietf.org/mail-archive/web/tram/current/msg00480.html >>at the end of the previous version of this draft that never became >>discussed and remain: >> >>A) Under 8.2 there is a suggested way to assure that the TURN server >>returned by the anycast method, is provided by the network provider >>(and not some far away TURN server that should not be trusted to use >>without authentication): "... can set an IP TTL on their TURN requests >>that limits how far they can travel into the public Internet." >> >>I suggest that this TTL limitation is specified (e.g. Don't look >>further than 3 steps - local firewall + max 2 ISP routers) and brought >>into section "5. Discovery using Anycast" of the draft. > >I think the decision should be left up to the application. We could, >maybe, >make a recommendation at best (i.e. it is not a MUST). > > >> >>B) Shall we really have more than one method? If the Anycast method can >>be used by everyone, why then also have DHCP and now a two more methods? > >There are essentially 2 methods described in the draft (1) Service >resolution and (2) Anycast. We'll probably need both if we want to >maximize >chances of discovery. >DHCP happens to be one method to obtain the domain-name for (1) Service >resolution. While the DHCP method may not workable in some cases, the >other >two methods (one of them inspired by draft-kist-alto-3pdisc) could offer >better results. We can do away with DHCP, if that is the WG consensus. > > >> >>I assume you intend that all webrtc browsers implement and can use all >>methods? Or? (If a service provider e.g. deploys DHCP discovered TURN >>servers, but some webrtc browser in some operating system don't >>find/cannot use the TURN server, it would be bad.) >> >>In previous discussions, there were some fears that DHCP options are >>not available in some common OSs. If so, I think the DHCP method should >>be skipped. >> >>Also, if the other methods (other than anycast) may fail, why have them? > >Anycast may fail, too. > > >>=20 >>Are they better to deploy and provision for network service providers? >> >>And will webrtc browsers implement all these methods? >> >>Do we have input/feedback on these questions? >> >>Should the "connect speed factor" not also be considered? Even though >>the auto discovery can be done in advance of a call, we should consider >>the mobility use case. With a mobile client changing network, >>LAN/LTE/public WiFi etc., we want to get up and run as soon as >>possible, so the auto discovery of a new TURN server should not be a >>tedious process >> >>And should the quick anycast auto discovery not be the first to be >>tried/used (which it is not now in the draft)? > >Given that there is a service resolution mechanism for TURN over DTLS >(http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it seems >useful to do service resolution before. > >> >>C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery >>is now RFC7216. > >Thanks, will update. > >-Prashanth > > >> >>/Karl >> >> >>-----Ursprungligt meddelande----- >>Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil >>(praspati) >>Skickat: den 2 maj 2014 12:02 >>Till: tram@ietf.org >>=C4mne: [tram] FW: New Version Notification for >>draft-patil-tram-turn-serv-disc-01.txt >> >>A new revision of the TURN server discovery draft has been published. >>Notable updates : >> >>* 300 (Try Alternate) response for anycast. >>* Mechanism described in draft-kist-alto-3pdisc i.e. using the clients >>own address to populate the DNS reverse zone (i.e., in-addr.arpa or >>ip6.arpa) with appropriate NAPTR records pointing to the TURN server. >>* Learning domain names from own identity. >> >>-Prashanth >> >> >>On 5/2/14 3:25 PM, "internet-drafts@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >>>has been successfully submitted by Prashanth Patil and posted to the >>>IETF repository. >>> >>>Name: draft-patil-tram-turn-serv-disc >>>Revision: 01 >>>Title: TURN Server Auto Discovery >>>Document date: 2014-05-02 >>>Group: Individual Submission >>>Pages: 11 >>>URL: =20 >>>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01 >>>.tx >>>t >>>Status: =20 >>>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >>>Htmlized: =20 >>>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >>>Diff: =20 >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 >>> >>>Abstract: >>> Current Traversal Using Relays around NAT (TURN) server discovery >>> mechanisms are relatively static and limited to explicit >>> configuration. These are usually under the administrative control of >>> the application or TURN service provider, and not the enterprise or >>> the ISP, the network in which the client is located. Enterprises and >>> ISPs wishing to provide their own TURN servers need auto discovery >>> mechanisms that a TURN client could use with no or minimal >>> configuration. This document describes two such mechanisms for TURN >>> server discovery. >>> >>> =20 >>> =20 >>> >>> >>>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 >> > >_______________________________________________ >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 May 20 02:59:41 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 67E491A0677 for ; Tue, 20 May 2014 02:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] 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 KVfVzHxOa3TV for ; Tue, 20 May 2014 02:59:36 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6E91A02B5 for ; Tue, 20 May 2014 02:59:34 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201405201159329859; Tue, 20 May 2014 11:59:32 +0200 From: "Karl Stahl" To: "'Prashanth Patil \(praspati\)'" , References: <069201cf73b1$948b5a80$bda20f80$@stahl@intertex.se> In-Reply-To: Date: Tue, 20 May 2014 11:59:29 +0200 Message-ID: <075201cf7412$3149b0a0$93dd11e0$@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: AQHPc43I/cHap6Ml70mhGHdWVtbuyJtIej/ggAFtsID//1PNMA== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/imVX3aQYCiZGIul4GwU8i9Ud1BY Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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, 20 May 2014 09:59:38 -0000 I think the draft should elaborate some around these (and Tiru's) = thoughts of having multiple methods. /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil = (praspati) Skickat: den 20 maj 2014 11:40 Till: tram@ietf.org =C4mne: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt On 5/20/14 3:57 AM, "Karl Stahl" wrote: >I read "We'll probably need both if we want to maximize chances of=20 >discovery." in the draft also, but don't really get it. > >Do you mean that if the network provider offers one particular TURN=20 >server to his network users, that TURN server should be advertised in=20 >both suggested ways? By maximize, the draft really means discovering servers that may not = support all discoverable methods. For example, if a provider already has TURN application service provisioned in DNS (as in RFC5928), it can be = readily discovered without needing anycast. -Prashanth =20 > >/Karl > >-----Ursprungligt meddelande----- >Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil=20 >(praspati) >Skickat: den 19 maj 2014 20:12 >Till: Karl Stahl; tram@ietf.org; 'Simon Perreault' >=C4mne: Re: [tram] New Version Notification for=20 >draft-patil-tram-turn-serv-disc-01.txt > >Hi Karl, > >On 5/18/14 6:13 PM, "Karl Stahl" wrote: > >>I browsed through this document and to me it looks mature enough to be = >>pushed forward (hopefully soon) to get an IANA anycast address etc.,=20 >>so these things can be put into current WebRTC browsers. As we know,=20 >>many enterprises cannot use WebRTC at all today due to their=20 >>restrictive firewall policies - they need a TURN server on their LAN,=20 >>discovered and used by the WebRTC browsers to even begin using WebRTC. >> >>However, I raised a few questions and some suggestions=20 >>http://www.ietf.org/mail-archive/web/tram/current/msg00480.html >>at the end of the previous version of this draft that never became=20 >>discussed and remain: >> >>A) Under 8.2 there is a suggested way to assure that the TURN server=20 >>returned by the anycast method, is provided by the network provider=20 >>(and not some far away TURN server that should not be trusted to use=20 >>without authentication): "... can set an IP TTL on their TURN requests = >>that limits how far they can travel into the public Internet." >> >>I suggest that this TTL limitation is specified (e.g. Don't look=20 >>further than 3 steps - local firewall + max 2 ISP routers) and brought = >>into section "5. Discovery using Anycast" of the draft. > >I think the decision should be left up to the application. We could,=20 >maybe, make a recommendation at best (i.e. it is not a MUST). > > >> >>B) Shall we really have more than one method? If the Anycast method=20 >>can be used by everyone, why then also have DHCP and now a two more methods? > >There are essentially 2 methods described in the draft (1) Service=20 >resolution and (2) Anycast. We'll probably need both if we want to=20 >maximize chances of discovery. >DHCP happens to be one method to obtain the domain-name for (1) Service = >resolution. While the DHCP method may not workable in some cases, the=20 >other two methods (one of them inspired by draft-kist-alto-3pdisc)=20 >could offer better results. We can do away with DHCP, if that is the=20 >WG consensus. > > >> >>I assume you intend that all webrtc browsers implement and can use all = >>methods? Or? (If a service provider e.g. deploys DHCP discovered TURN=20 >>servers, but some webrtc browser in some operating system don't=20 >>find/cannot use the TURN server, it would be bad.) >> >>In previous discussions, there were some fears that DHCP options are=20 >>not available in some common OSs. If so, I think the DHCP method=20 >>should be skipped. >> >>Also, if the other methods (other than anycast) may fail, why have = them? > >Anycast may fail, too. > > >>=20 >>Are they better to deploy and provision for network service providers? >> >>And will webrtc browsers implement all these methods? >> >>Do we have input/feedback on these questions? >> >>Should the "connect speed factor" not also be considered? Even though=20 >>the auto discovery can be done in advance of a call, we should=20 >>consider the mobility use case. With a mobile client changing network, = >>LAN/LTE/public WiFi etc., we want to get up and run as soon as=20 >>possible, so the auto discovery of a new TURN server should not be a=20 >>tedious process >> >>And should the quick anycast auto discovery not be the first to be=20 >>tried/used (which it is not now in the draft)? > >Given that there is a service resolution mechanism for TURN over DTLS=20 >(http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it=20 >seems useful to do service resolution before. > >> >>C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery >>is now RFC7216. > >Thanks, will update. > >-Prashanth > > >> >>/Karl >> >> >>-----Ursprungligt meddelande----- >>Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil >>(praspati) >>Skickat: den 2 maj 2014 12:02 >>Till: tram@ietf.org >>=C4mne: [tram] FW: New Version Notification for=20 >>draft-patil-tram-turn-serv-disc-01.txt >> >>A new revision of the TURN server discovery draft has been published. >>Notable updates : >> >>* 300 (Try Alternate) response for anycast. >>* Mechanism described in draft-kist-alto-3pdisc i.e. using the clients = >>own address to populate the DNS reverse zone (i.e., in-addr.arpa or >>ip6.arpa) with appropriate NAPTR records pointing to the TURN server. >>* Learning domain names from own identity. >> >>-Prashanth >> >> >>On 5/2/14 3:25 PM, "internet-drafts@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >>>has been successfully submitted by Prashanth Patil and posted to the=20 >>>IETF repository. >>> >>>Name: draft-patil-tram-turn-serv-disc >>>Revision: 01 >>>Title: TURN Server Auto Discovery >>>Document date: 2014-05-02 >>>Group: Individual Submission >>>Pages: 11 >>>URL: =20 >>>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-0 >>>1 >>>.tx >>>t >>>Status: =20 >>>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >>>Htmlized: =20 >>>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >>>Diff: =20 >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 >>> >>>Abstract: >>> Current Traversal Using Relays around NAT (TURN) server discovery >>> mechanisms are relatively static and limited to explicit >>> configuration. These are usually under the administrative control = of >>> the application or TURN service provider, and not the enterprise = or >>> the ISP, the network in which the client is located. Enterprises = and >>> ISPs wishing to provide their own TURN servers need auto discovery >>> mechanisms that a TURN client could use with no or minimal >>> configuration. This document describes two such mechanisms for = TURN >>> server discovery. >>> >>> =20 >>> =20 >>> >>> >>>Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >> >>_______________________________________________ >>tram mailing list >>tram@ietf.org >>https://www.ietf.org/mailman/listinfo/tram >> > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Tue May 20 05:35: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 3553B1A0683 for ; Tue, 20 May 2014 05:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] 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 1LbHYoka3TLt for ; Tue, 20 May 2014 05:35:52 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3BE1A0357 for ; Tue, 20 May 2014 05:35:50 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201405201435453059; Tue, 20 May 2014 14:35:45 +0200 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Prashanth Patil \(praspati\)'" , , "'Simon Perreault'" References: <069201cf73b1$948b5a80$bda20f80$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A24335B49@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A24335B49@xmb-rcd-x10.cisco.com> Date: Tue, 20 May 2014 14:35:43 +0200 Message-ID: <079501cf7428$0490b520$0db21f60$@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: AQHPc43INN+P5dH8gUSyAQOmv2KoiJtIz96AgAA+0DCAAFRjQA== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ShVzCfHYsujiKqr49F7d-yRehVk Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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, 20 May 2014 12:35:54 -0000 In this multiple methods discussion, what about this WebRTC use case = that I think will be common: An enterprise installs a TURN server with one LAN-port (paralleling its firewall), because it wants to use WebRTC but maintain a restrictive firewall policy, that stops WebRTC media or it wants to have a better = media path than through his ordinary data crowded Internet access. Would it then be sufficient to add a route in its ordinary firewall, so = the anycast-address goes to that local TURN-server - and the Web-browsers = really use that path? I don't see the enterprise wanting to set up other discovery methods = also. /Karl -----Ursprungligt meddelande----- Fr=E5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 20 maj 2014 09:14 Till: Karl Stahl; Prashanth Patil (praspati); tram@ietf.org; 'Simon Perreault' =C4mne: RE: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > Sent: Tuesday, May 20, 2014 3:58 AM > To: Prashanth Patil (praspati); tram@ietf.org; 'Simon Perreault' > Subject: Re: [tram] New Version Notification for=20 > draft-patil-tram-turn-serv-disc- 01.txt >=20 > I read "We'll probably need both if we want to maximize chances of=20 > discovery." in the draft also, but don't really get it. With Secure DHCPv6 with Public Key http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02, DHCP has benefits over Anycast. But since DHCP is not workable in some cases, clients may end-up using = both the techniques (for e.g. use happy-eyeball mechanism) and give = precedence to TURN server learnt using secure DHCP. >=20 > Do you mean that if the network provider offers one particular TURN=20 > server to his network users, that TURN server should be advertised in=20 > both suggested ways? Yes -Tiru By maximize, the draft really means discovering servers that may not = support all discoverable methods. For example, if a provider already has TURN application service provisioned in DNS (as in RFC5928), it can be = readily discovered without needing anycast. -Prashanth >=20 > /Karl >=20 > -----Ursprungligt meddelande----- > Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil=20 > (praspati) > Skickat: den 19 maj 2014 20:12 > Till: Karl Stahl; tram@ietf.org; 'Simon Perreault' > =C4mne: Re: [tram] New Version Notification for=20 > draft-patil-tram-turn-serv-disc-01.txt >=20 > Hi Karl, >=20 > On 5/18/14 6:13 PM, "Karl Stahl" wrote: >=20 > >I browsed through this document and to me it looks mature enough to=20 > >be pushed forward (hopefully soon) to get an IANA anycast address=20 > >etc., so these things can be put into current WebRTC browsers. As we=20 > >know, many enterprises cannot use WebRTC at all today due to their=20 > >restrictive firewall policies - they need a TURN server on their LAN, = > >discovered and used by the WebRTC browsers to even begin using = WebRTC. > > > >However, I raised a few questions and some suggestions=20 > >http://www.ietf.org/mail-archive/web/tram/current/msg00480.html > >at the end of the previous version of this draft that never became=20 > >discussed and remain: > > > >A) Under 8.2 there is a suggested way to assure that the TURN server=20 > >returned by the anycast method, is provided by the network provider=20 > >(and not some far away TURN server that should not be trusted to use=20 > >without authentication): "... can set an IP TTL on their TURN=20 > >requests that limits how far they can travel into the public = Internet." > > > >I suggest that this TTL limitation is specified (e.g. Don't look=20 > >further than 3 steps - local firewall + max 2 ISP routers) and=20 > >brought into section "5. Discovery using Anycast" of the draft. >=20 > I think the decision should be left up to the application. We could,=20 > maybe, make a recommendation at best (i.e. it is not a MUST). >=20 >=20 > > > >B) Shall we really have more than one method? If the Anycast method=20 > >can be used by everyone, why then also have DHCP and now a two more methods? >=20 > There are essentially 2 methods described in the draft (1) Service=20 > resolution and (2) Anycast. We'll probably need both if we want to=20 > maximize chances of discovery. > DHCP happens to be one method to obtain the domain-name for (1)=20 > Service resolution. While the DHCP method may not workable in some=20 > cases, the other two methods (one of them inspired by=20 > draft-kist-alto-3pdisc) could offer better results. We can do away = with DHCP, if that is the WG consensus. >=20 >=20 > > > >I assume you intend that all webrtc browsers implement and can use=20 > >all methods? Or? (If a service provider e.g. deploys DHCP discovered=20 > >TURN servers, but some webrtc browser in some operating system don't=20 > >find/cannot use the TURN server, it would be bad.) > > > >In previous discussions, there were some fears that DHCP options are=20 > >not available in some common OSs. If so, I think the DHCP method=20 > >should be skipped. > > > >Also, if the other methods (other than anycast) may fail, why have = them? >=20 > Anycast may fail, too. >=20 >=20 > > > >Are they better to deploy and provision for network service = providers? > > > >And will webrtc browsers implement all these methods? > > > >Do we have input/feedback on these questions? > > > >Should the "connect speed factor" not also be considered? Even though = > >the auto discovery can be done in advance of a call, we should=20 > >consider the mobility use case. With a mobile client changing=20 > >network, LAN/LTE/public WiFi etc., we want to get up and run as soon=20 > >as possible, so the auto discovery of a new TURN server should not be = > >a tedious process > > > >And should the quick anycast auto discovery not be the first to be=20 > >tried/used (which it is not now in the draft)? >=20 > Given that there is a service resolution mechanism for TURN over DTLS=20 > (http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it=20 > seems useful to do service resolution before. >=20 > > > >C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery > >is now RFC7216. >=20 > Thanks, will update. >=20 > -Prashanth >=20 >=20 > > > >/Karl > > > > > >-----Ursprungligt meddelande----- > >Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil > >(praspati) > >Skickat: den 2 maj 2014 12:02 > >Till: tram@ietf.org > >=C4mne: [tram] FW: New Version Notification for=20 > >draft-patil-tram-turn-serv-disc-01.txt > > > >A new revision of the TURN server discovery draft has been published. > >Notable updates : > > > >* 300 (Try Alternate) response for anycast. > >* Mechanism described in draft-kist-alto-3pdisc i.e. using the=20 > >clients own address to populate the DNS reverse zone (i.e.,=20 > >in-addr.arpa or > >ip6.arpa) with appropriate NAPTR records pointing to the TURN server. > >* Learning domain names from own identity. > > > >-Prashanth > > > > > >On 5/2/14 3:25 PM, "internet-drafts@ietf.org" > > > >wrote: > > > >> > >>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt > >>has been successfully submitted by Prashanth Patil and posted to the = > >>IETF repository. > >> > >>Name: draft-patil-tram-turn-serv-disc > >>Revision: 01 > >>Title: TURN Server Auto Discovery > >>Document date: 2014-05-02 > >>Group: Individual Submission > >>Pages: 11 > >>URL: > >>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc- > >>01 > >>.tx > >>t > >>Status: > >>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ > >>Htmlized: > >>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 > >>Diff: > = >>http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 > >> > >>Abstract: > >> Current Traversal Using Relays around NAT (TURN) server discovery > >> mechanisms are relatively static and limited to explicit > >> configuration. These are usually under the administrative = control of > >> the application or TURN service provider, and not the enterprise = or > >> the ISP, the network in which the client is located. Enterprises = and > >> ISPs wishing to provide their own TURN servers need auto = discovery > >> mechanisms that a TURN client could use with no or minimal > >> configuration. This document describes two such mechanisms for = TURN > >> server discovery. > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of=20 > >>submission until the htmlized version and diff are available at=20 > >>tools.ietf.org. > >> > >>The IETF Secretariat > >> > > > >_______________________________________________ > >tram mailing list > >tram@ietf.org > >https://www.ietf.org/mailman/listinfo/tram > > >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue May 20 07:53:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA341A0366 for ; Tue, 20 May 2014 07:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 o3LhFQ7SvCnB for ; Tue, 20 May 2014 07:53:31 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 497B01A072F for ; Tue, 20 May 2014 07:53:31 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 320221EB8534; Tue, 20 May 2014 16:53:30 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Tue, 20 May 2014 16:53:30 +0200 From: "Stach, Thomas" To: "draft-ietf-tram-stun-dtls@tools.ietf.org" Thread-Topic: [tram] WGLC: draft-ietf-tram-stun-dtls-02 - review Thread-Index: AQHPaPnuXTJYHqKpb0Svtr0ty3BESJtJoEHQ Date: Tue, 20 May 2014 14:53:29 +0000 Message-ID: References: <53688A4D.8050208@ericsson.com> In-Reply-To: <53688A4D.8050208@ericsson.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nbdjZGb8OyI4RvhOWRvSVQGb4IA Cc: Gonzalo Camarillo , "tram@ietf.org" Subject: [tram] WGLC: draft-ietf-tram-stun-dtls-02 - review 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, 20 May 2014 14:53:33 -0000 Marc, Gonzalo, I did a review of your draft and, though the draft is in good shape,=20 I came across some points which were not clear to me. Section 3 DTLS as Transport for STUN ... STUN over DTLS MUST, at a minimum, support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support TLS_RSA_WITH_AES_128_CBC_SHA. =20 The first MUST is qualified with "at a minimum". Should that indicate that the second MUST is not really a MUST?=20 If not, then you might want to remove "at a minimum". If yes, use RECOMMENDED for TLS_RSA_WITH_AES_128_CBC_SHA. The STUN over TLS default cipher suite was TLS_RSA_WITH_AES_128_CBC_SHA.=20 Are both cipher suites above meant as addition to the TLS default or as a r= eplacement? I propose to clarify either with "In addition to TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher s= uite for STUN over TLS, STUN over DTLS implementation MUST support ." or "Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher suite= for STUN over TLS, STUN over DTLS implementation MUST support ." Section 4. STUN Usages The link in "[RFC5389] Section 7.2 ." points to section 7.2 of this draft.= =20 Similar links in the draft point directly to the relevant RFC.=20 You may want to change this link accordingly. Section 4.1 NAT Discovery Usage ... Regardless, this usage is rarely used by itself, since TURN [RFC5766] is generally mandatory to use with ICE [RFC5245], and TURN provides the same NAT Discovery feature as part of an Allocation creation. In fact, with ICE, the NAT Discovery usage is only used when there is no longer any resource available for new Allocations in the TURN server. TURN support is not mandated in RFC5245, it is only at SHOULD strength.=20 See http://tools.ietf.org/html/rfc5245#section-4.1.1.2. =20 The easiest fix is probably to remove that whole paragraph. 4.2. Connectivity Check Usage ..=20 This usage MUST NOT be used with a STUN URI. It is not obvious to me what is meant here.=20 Do you want say that connectivity checks MUST NOT be sent over DTLS? MUST NOT is maybe a bit strong, but I would not object violently. 4.3. Media Keep-Alive Usage The media keep-alive (described in Section 20 of [RFC5245]) runs inside an RTP or RTCP session, so it is already protected if the RTP or RTCP session is also protected (i.e., SRTP/SRTCP). Adding DTLS inside the SRTP/SRTCP session would add overhead, with minimal security benefit. This usage MUST NOT be used with a STUN URI. I think the first sentence is a bit misleading. Media keep alive is separat= e from the RTP or SRTP session.=20 The STUN Binding indications are just multiplexed on the same port as (S)RT= P/(S)RTCP.=20 Sending the STUN Binding indication in DTLS records would however change ho= w this multiplexing is done, and as stated, would add overhead and initiall= y some delay.=20 Again I can't parse "This usage MUST NOT be used with a STUN URI."=20 Do you mean "STUN Binding indications MUST NOT be sent over DTLS"? 4.4. SIP Keep-Alive Usage . This usage MUST NOT be used with a STUN URI. As above it is not clear to me what is meant. Kind Regards/mit freundlichen Gr=FC=DFen Thomas Stach > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Dienstag, 6. Mai 2014 09:08 > To: tram@ietf.org > Subject: [tram] WGLC: draft-ietf-tram-stun-dtls-02 >=20 > Folks, >=20 > we are starting a Working Group Last Call (WGLC) on the following draft: >=20 > http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ >=20 > This WGLC will end on May 21st. Please, send your comments to this list. >=20 > Thanks, >=20 > Gonzalo >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed May 21 08:38: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 9F9371A0445 for ; Wed, 21 May 2014 08:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 l07Wfr-lOvqr for ; Wed, 21 May 2014 08:38:05 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1E61A06D6 for ; Wed, 21 May 2014 08:38:02 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id uy17so6349344igb.17 for ; Wed, 21 May 2014 08:38:01 -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=7vhSIDbEXc38ozlOhUjWCFvi3ELMfZuBWWdK/iZMxAo=; b=NghuinBbgvwC/C34qDMqr4DGNTnCePoUvOZ/RTrEWaYiOwN7fbi87F0MdmtPLJvqdH q3CyTmff4Ck5QYflYiVSR1OA2VOkVmZrSLbU1RJH6FSpMAdVIJTBGcjGK98jznjD/dg9 ZXynRgmyj0b4RpvKZ7E8SfgZqDoL4PfjtasSo= 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=7vhSIDbEXc38ozlOhUjWCFvi3ELMfZuBWWdK/iZMxAo=; b=D0fAjGvJbfl+QB80OD1bO/cbVoNqUacKlOTrkvgsX1jKGuzdFIoFOiCQiVsiLHO7lV KgNMknx7cy+BVHILA+ECIPpu7lcO8Ot2LbJkxZ0N/xnH4QnKd1sYlLQHOGXGEWCitZGa AwyTGHoIbxP8Vv4tbzRQZ14tl9F7IP/jsMXC1mDXMJoK2fcRvdw6CDQyLYWOv/Q1+fZT tcdXtWHbtIz0dp9NlZUTKArbkTdTjMYLXAoa/srTrovvQPtRaMra2pq62jLHS4oWc3Cv ycqwAOQGMKP52p3iD+yu0a2krzmDeYAuaYxIrCUov5D9FoXb3xkLW7kpXy7ZvUsKluE9 X01w== X-Gm-Message-State: ALoCoQmK/3hHoICqr0Qe3uLOwGaLCtXvchiroG130VOhaweaqEeG0pefLD03CUfIjCnl1hAATzzP X-Received: by 10.50.152.38 with SMTP id uv6mr14671493igb.34.1400686681356; Wed, 21 May 2014 08:38:01 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id l5sm5957495igt.0.2014.05.21.08.38.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 08:38:00 -0700 (PDT) Message-ID: <537CC853.6080709@getjive.com> Date: Wed, 21 May 2014 09:37:55 -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: Simon Perreault , tram@ietf.org References: <536734AA.2050006@ericsson.com> <536A0326.7040704@getjive.com> <53765692.60509@per.reau.lt> <537668D3.3020501@acm.org> <53768217.7070909@per.reau.lt> In-Reply-To: <53768217.7070909@per.reau.lt> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jEgdUddgADReIm4cnFO0jVorUIHjiedFc" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_s9eEmFX1rgX8HST-n0xWUGxrNs Subject: Re: [tram] Request to update STUN's IANA registration in STUNbis work 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, 21 May 2014 15:38:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jEgdUddgADReIm4cnFO0jVorUIHjiedFc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is another thing that in missing in RFC 5764. Because of ICE, a socket can receive TURN packets in addition to the STUN connectivity check packets not going through a relay (in this case the source IP:port is used to differentiate them). That's not an issue - unless the TURN server is using channels because in this case packets starting with a channel number will be received. That will work because the first byte will be in the 64-127 range, which is not used, but this is still something missing from RFC 5764. So my proposal is to update RFC 5764 changing the multiplexing algorithm like this: 0-19: STUN 20-63: DTLS 64-127: TURN channels 128-191: RTP/RTCP 191-255: unallocated Channel numbers 0x8000-0xFFFF will also have to be reserved in IANA's TURN Channel Numbers Registry. On 5/16/14, 3:24 PM, Simon Perreault wrote: > Le 2014-05-16 15:36, Marc Petit-Huguenin a =C3=A9crit : >>> I'm unable to find a justification for 19 < B < 64 --> DTLS. Can anyo= ne >>> please spell it out for me? I'm just going to assume it is correct. >> >> It's not, as it restricts TLS ContentType: >> >> http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tl= s-parameters-5. >> >> >> At a minimum 0-19 and 64-255 should be marked as reserved. >=20 > Wow. So both DTLS and STUN are equally affected by RFC 5764. >=20 > If we restrict STUN to work with RFC 5764, it would make sense that the= > DTLS folks do the same. >=20 > Also, it now seems impossible to just fix RFC 5764 on its own without > touching at least DTLS. >=20 > The DTLS folks need to get involved in this discussion... >=20 --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --jEgdUddgADReIm4cnFO0jVorUIHjiedFc 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/ iQEcBAEBAgAGBQJTfMhXAAoJEMUNRP98lsiXyEgH/RHJRSJBDyvKS3h0lBjv7kPq RTMkXctNzzjH9uoDW3MWD2HUe0TArgFph24KukDX3tst+EjfZ5sT+gzO2RZG9z0q mAJfeio/Q8pgNmFxFBpocsvhj5NpCUiDYP71pvo4tfFOiZK36W8ahcpTJtRz4IGm cLONhZa1/yuR/B4M3enbeVbU6jy94RGf3G3StDKzDYUukSSqOPnVvofGzFXkoU72 3ASwDMx/xbJXiAvtmrxs/oLVis9nvb6dNjXrkz2WrY+TdmzplJp30C+OHx79Fo+K Ph2fRNc9IHSFNtz2hpvbgYKrq1eorpXuzBz5PIQ0xYIqjhj9gNboUjPJmIRbzfQ= =uUzP -----END PGP SIGNATURE----- --jEgdUddgADReIm4cnFO0jVorUIHjiedFc-- From nobody Wed May 21 09:17:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22E81A0346 for ; Wed, 21 May 2014 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_24=0.6, SPF_HELO_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 Gw6Y_3w26BZ4 for ; Wed, 21 May 2014 09:17:32 -0700 (PDT) Received: from nomis80.org (nomis80.org [23.92.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id D8E4B1A032F for ; Wed, 21 May 2014 09:17:28 -0700 (PDT) Received: from [IPv6:2001:470:1d:bc0:8494:164e:8f26:9cc7] (unknown [IPv6:2001:470:1d:bc0:8494:164e:8f26:9cc7]) by nomis80.org (Postfix) with ESMTPSA id 762CE10EB4; Wed, 21 May 2014 16:18:44 +0000 (UTC) Message-ID: <537CD195.903@per.reau.lt> Date: Wed, 21 May 2014 12:17:25 -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: Marc Petit-Huguenin , tram@ietf.org References: <536734AA.2050006@ericsson.com> <536A0326.7040704@getjive.com> <53765692.60509@per.reau.lt> <537668D3.3020501@acm.org> <53768217.7070909@per.reau.lt> <537CC853.6080709@getjive.com> In-Reply-To: <537CC853.6080709@getjive.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_19fRxfP51p5n8SHhy8exXmFHo4 Subject: Re: [tram] Request to update STUN's IANA registration in STUNbis work 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, 21 May 2014 16:17:33 -0000 Le 2014-05-21 11:37, Marc Petit-Huguenin a écrit : > There is another thing that in missing in RFC 5764. Because of ICE, a > socket can receive TURN packets in addition to the STUN connectivity > check packets not going through a relay (in this case the source IP:port > is used to differentiate them). That's not an issue - unless the TURN > server is using channels because in this case packets starting with a > channel number will be received. That will work because the first byte > will be in the 64-127 range, which is not used, but this is still > something missing from RFC 5764. Correct. > So my proposal is to update RFC 5764 changing the multiplexing algorithm > like this: > > 0-19: STUN > 20-63: DTLS > 64-127: TURN channels > 128-191: RTP/RTCP > 191-255: unallocated > > Channel numbers 0x8000-0xFFFF will also have to be reserved in IANA's > TURN Channel Numbers Registry. Seems correct to me. I think at this point we need to start a thread in the TLS working group. Would you mind doing it? When we have a clear cross-area understanding of what needs to be done, the hard part will be over. Thanks, Simon From nobody Wed May 21 09:23:15 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 66C2C1A0845 for ; Wed, 21 May 2014 09:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 8C9vWJEDgGUz for ; Wed, 21 May 2014 09:23:10 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717421A072E for ; Wed, 21 May 2014 09:23:10 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id uy17so5118173igb.3 for ; Wed, 21 May 2014 09:23:09 -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=jTE6Eb3RgkTCyhXj944GSjRD1mkHC+xHjpBgDGnAnIw=; b=IHNfO2WxLc0/CSTNVdc4XDwhliygrj1bY96iXPPcMsK2JpnL4NeXZeJc6NEgV+RPl9 56QiWWIKhdvIQ4mMSYLghdBoFqzWNCKD7hxngLj3NxGo7YEFtmjSJUiSw1Woq1VmBkF+ wpEQsGMjxmbNnQnCVJ/iMvgMmoFVTXDohBRbg= 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=jTE6Eb3RgkTCyhXj944GSjRD1mkHC+xHjpBgDGnAnIw=; b=CYOTabEufdyOHUoLBU4Cg1EkQ113ss4DahhYvHfwUZ8BLrkWp+2aSsqB7rhNknxQCY JRzrWJhOAd1xDD2CnE4/rs9gSdo+rdc/vBA9bkBu9E3SBc/QCbJuOLjSMJX1I1viLuNd LRcb7BqVkVqQpZNPnCBcCc9JQ557F+vZvXI1tlVlZhxkyFgkDjxyhPsERegqdkBcuR5B xdKcd2XZo/tI92J65OkftmdDmQyRjPBtv+jk14qH63VWnmT7Sn+UsrFhvLp/C63/kNVS DNMMOPHCvDBS3ahDVArVJvHZdSbrsILQNuxFrJ+Rgan2pK1LhER8F/iZ6/iBCkVTvHL/ xxiw== X-Gm-Message-State: ALoCoQlZhy2OMLGWMzS7bcDmXWVRwNbUMr0yPpUwTQACiu+t9DYuWbOZvwDT7yWEbu9KOzWoT8aZ X-Received: by 10.42.58.130 with SMTP id i2mr19409853ich.66.1400689389196; Wed, 21 May 2014 09:23:09 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id fx1sm6226383igd.1.2014.05.21.09.23.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 09:23:08 -0700 (PDT) Message-ID: <537CD2E6.30400@getjive.com> Date: Wed, 21 May 2014 10:23:02 -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: Simon Perreault , tram@ietf.org References: <536734AA.2050006@ericsson.com> <536A0326.7040704@getjive.com> <53765692.60509@per.reau.lt> <537668D3.3020501@acm.org> <53768217.7070909@per.reau.lt> <537CC853.6080709@getjive.com> <537CD195.903@per.reau.lt> In-Reply-To: <537CD195.903@per.reau.lt> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrSHokm6q7iQC4Mnnjllr0pcXdV7Pi4wH" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/AiVIBhmoZ4yhdwyTx7MgAq4dnxM Subject: Re: [tram] Request to update STUN's IANA registration in STUNbis work 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, 21 May 2014 16:23:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lrSHokm6q7iQC4Mnnjllr0pcXdV7Pi4wH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/21/14, 10:17 AM, Simon Perreault wrote: > Le 2014-05-21 11:37, Marc Petit-Huguenin a =C3=A9crit : >> There is another thing that in missing in RFC 5764. Because of ICE, a= >> socket can receive TURN packets in addition to the STUN connectivity >> check packets not going through a relay (in this case the source IP:po= rt >> is used to differentiate them). That's not an issue - unless the TURN= >> server is using channels because in this case packets starting with a >> channel number will be received. That will work because the first byt= e >> will be in the 64-127 range, which is not used, but this is still >> something missing from RFC 5764. >=20 > Correct. >=20 >> So my proposal is to update RFC 5764 changing the multiplexing algorit= hm >> like this: >> >> 0-19: STUN >> 20-63: DTLS >> 64-127: TURN channels >> 128-191: RTP/RTCP >> 191-255: unallocated >> >> Channel numbers 0x8000-0xFFFF will also have to be reserved in IANA's >> TURN Channel Numbers Registry. >=20 > Seems correct to me. >=20 > I think at this point we need to start a thread in the TLS working > group. Would you mind doing it? >=20 > When we have a clear cross-area understanding of what needs to be done,= > the hard part will be over. >=20 OK, I'll send something before the week-end. --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --lrSHokm6q7iQC4Mnnjllr0pcXdV7Pi4wH 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/ iQEcBAEBAgAGBQJTfNLrAAoJEMUNRP98lsiXDB4H/3Gw0neZVdRs0C//IpJhuHqs wxKUxhB5vZSsEMbaFZUuk0iusgL8WWC/9ThAI9TBvIEG5DQj2DANwq8LEBhup0DW vvm5qfTg9674594jSWfnnYuLHAWepIiTDfKDyvUK/B8iaUocfkxKbjh06LHjsS58 fjM624inpymERdNB3LTeBC899UQb5WMcdKl1iGEtr4rI8BgZwHz+DkSERg3eyHD9 YlyqlbrnCsEnLgo42b9e4hy8OjsPAzIUsT2fC/IVF/NBJH8w6p+Q4Exag9uVzJM+ nmuxF8c68s66CYU7DEoq5LJwrCG05GCRAX7NkTUkpGzaHDff4I8Jf6vuOpGXcts= =UTKB -----END PGP SIGNATURE----- --lrSHokm6q7iQC4Mnnjllr0pcXdV7Pi4wH-- From nobody Wed May 21 10:17: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 4806B1A01E1 for ; Wed, 21 May 2014 10:17:21 -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 asHvgj1yWl5i for ; Wed, 21 May 2014 10:17:19 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA78B1A0879 for ; Wed, 21 May 2014 10:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10569; q=dns/txt; s=iport; t=1400692638; x=1401902238; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=S0ys0Wy3VMTNOtnt+nLO5huBKLS3eTE0oWXZ9/hw+wo=; b=GEuWiLpLiPtvURi9lshqYGU67vCqeesSfewJgaWDJbXBvZfcd0WE+11l JBIe4MHvOjN5lFNQKMAKzwgfRwk1CvRWgDMKY7wzbdKfCEduXQAYfoHht xXcea8oJJ0047U23GDK5afdEIvkbVdZzW+1x6I+Z4tdQisXrZCKtLVFYk M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYIABPffFOtJV2P/2dsb2JhbABQCYMJUlEHvGCHOwGBDBZ0giUBAQEEAQEBagEJDgYBCBEEAQEBCh0uCxQJCQEEARIIAYg4CAXWSReJMIRDAwcBAR4zC4MlgRUEiWaRRZFngzhtgQEJFyI X-IronPort-AV: E=Sophos;i="4.98,881,1392163200"; d="scan'208";a="45921110" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 21 May 2014 17:17:15 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4LHHFcb003177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 17:17:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 21 May 2014 12:17:15 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Karl Stahl , "Prashanth Patil (praspati)" , "tram@ietf.org" , "'Simon Perreault'" Thread-Topic: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt Thread-Index: Ac91GHqR/nbc2tHQT56l8am6h3Zpaw== Date: Wed, 21 May 2014 17:17:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2433691A@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.72.164] 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/Krgi3D7NA16PkDKaAUnbiepQkQs Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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, 21 May 2014 17:17:21 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > Sent: Tuesday, May 20, 2014 6:06 PM > To: Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); tram@ietf.o= rg; > 'Simon Perreault' > Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-se= rv-disc- > 01.txt >=20 > In this multiple methods discussion, what about this WebRTC use case that= I > think will be common: >=20 > An enterprise installs a TURN server with one LAN-port (paralleling its f= irewall), > because it wants to use WebRTC but maintain a restrictive firewall policy= , that > stops WebRTC media or it wants to have a better media path than through h= is > ordinary data crowded Internet access. > > Would it then be sufficient to add a route in its ordinary firewall, so t= he anycast- > address goes to that local TURN-server - and the Web-browsers really use = that > path? >=20 > I don't see the enterprise wanting to set up other discovery methods also= . Enterprise firewall policies to permit WebRTC media and data channels is an= interesting problem it was discussed in pntaw ietf mailing list sometime b= ack. Various mechanisms like http://tools.ietf.org/html/draft-hutton-rtcweb= -nat-firewall-considerations-03, PCP etc were discussed. As far as I rememb= er there was no conclusion that only anycast approach would work.=20 Cheers, -Tiru >=20 > /Karl >=20 >=20 > -----Ursprungligt meddelande----- > Fr=E5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Skickat: den 20 maj 2014 09:14 > Till: Karl Stahl; Prashanth Patil (praspati); tram@ietf.org; 'Simon Perre= ault' > =C4mne: RE: [tram] New Version Notification for draft-patil-tram-turn-ser= v-disc- > 01.txt >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > > Sent: Tuesday, May 20, 2014 3:58 AM > > To: Prashanth Patil (praspati); tram@ietf.org; 'Simon Perreault' > > Subject: Re: [tram] New Version Notification for > > draft-patil-tram-turn-serv-disc- 01.txt > > > > I read "We'll probably need both if we want to maximize chances of > > discovery." in the draft also, but don't really get it. >=20 > With Secure DHCPv6 with Public Key > http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02, DHCP has benefits = over > Anycast. > But since DHCP is not workable in some cases, clients may end-up using bo= th the > techniques (for e.g. use happy-eyeball mechanism) and give precedence to = TURN > server learnt using secure DHCP. >=20 > > > > Do you mean that if the network provider offers one particular TURN > > server to his network users, that TURN server should be advertised in > > both suggested ways? >=20 > Yes >=20 > -Tiru >=20 > By maximize, the draft really means discovering servers that may not supp= ort all > discoverable methods. For example, if a provider already has TURN applica= tion > service provisioned in DNS (as in RFC5928), it can be readily discovered = without > needing anycast. >=20 > -Prashanth >=20 > > > > /Karl > > > > -----Ursprungligt meddelande----- > > Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil > > (praspati) > > Skickat: den 19 maj 2014 20:12 > > Till: Karl Stahl; tram@ietf.org; 'Simon Perreault' > > =C4mne: Re: [tram] New Version Notification for > > draft-patil-tram-turn-serv-disc-01.txt > > > > Hi Karl, > > > > On 5/18/14 6:13 PM, "Karl Stahl" wrote: > > > > >I browsed through this document and to me it looks mature enough to > > >be pushed forward (hopefully soon) to get an IANA anycast address > > >etc., so these things can be put into current WebRTC browsers. As we > > >know, many enterprises cannot use WebRTC at all today due to their > > >restrictive firewall policies - they need a TURN server on their LAN, > > >discovered and used by the WebRTC browsers to even begin using WebRTC. > > > > > >However, I raised a few questions and some suggestions > > >http://www.ietf.org/mail-archive/web/tram/current/msg00480.html > > >at the end of the previous version of this draft that never became > > >discussed and remain: > > > > > >A) Under 8.2 there is a suggested way to assure that the TURN server > > >returned by the anycast method, is provided by the network provider > > >(and not some far away TURN server that should not be trusted to use > > >without authentication): "... can set an IP TTL on their TURN > > >requests that limits how far they can travel into the public Internet.= " > > > > > >I suggest that this TTL limitation is specified (e.g. Don't look > > >further than 3 steps - local firewall + max 2 ISP routers) and > > >brought into section "5. Discovery using Anycast" of the draft. > > > > I think the decision should be left up to the application. We could, > > maybe, make a recommendation at best (i.e. it is not a MUST). > > > > > > > > > >B) Shall we really have more than one method? If the Anycast method > > >can be used by everyone, why then also have DHCP and now a two more > methods? > > > > There are essentially 2 methods described in the draft (1) Service > > resolution and (2) Anycast. We'll probably need both if we want to > > maximize chances of discovery. > > DHCP happens to be one method to obtain the domain-name for (1) > > Service resolution. While the DHCP method may not workable in some > > cases, the other two methods (one of them inspired by > > draft-kist-alto-3pdisc) could offer better results. We can do away > > with > DHCP, if that is the WG consensus. > > > > > > > > > >I assume you intend that all webrtc browsers implement and can use > > >all methods? Or? (If a service provider e.g. deploys DHCP discovered > > >TURN servers, but some webrtc browser in some operating system don't > > >find/cannot use the TURN server, it would be bad.) > > > > > >In previous discussions, there were some fears that DHCP options are > > >not available in some common OSs. If so, I think the DHCP method > > >should be skipped. > > > > > >Also, if the other methods (other than anycast) may fail, why have the= m? > > > > Anycast may fail, too. > > > > > > > > > >Are they better to deploy and provision for network service providers? > > > > > >And will webrtc browsers implement all these methods? > > > > > >Do we have input/feedback on these questions? > > > > > >Should the "connect speed factor" not also be considered? Even though > > >the auto discovery can be done in advance of a call, we should > > >consider the mobility use case. With a mobile client changing > > >network, LAN/LTE/public WiFi etc., we want to get up and run as soon > > >as possible, so the auto discovery of a new TURN server should not be > > >a tedious process > > > > > >And should the quick anycast auto discovery not be the first to be > > >tried/used (which it is not now in the draft)? > > > > Given that there is a service resolution mechanism for TURN over DTLS > > (http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it > > seems useful to do service resolution before. > > > > > > > >C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery > > >is now RFC7216. > > > > Thanks, will update. > > > > -Prashanth > > > > > > > > > >/Karl > > > > > > > > >-----Ursprungligt meddelande----- > > >Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil > > >(praspati) > > >Skickat: den 2 maj 2014 12:02 > > >Till: tram@ietf.org > > >=C4mne: [tram] FW: New Version Notification for > > >draft-patil-tram-turn-serv-disc-01.txt > > > > > >A new revision of the TURN server discovery draft has been published. > > >Notable updates : > > > > > >* 300 (Try Alternate) response for anycast. > > >* Mechanism described in draft-kist-alto-3pdisc i.e. using the > > >clients own address to populate the DNS reverse zone (i.e., > > >in-addr.arpa or > > >ip6.arpa) with appropriate NAPTR records pointing to the TURN server. > > >* Learning domain names from own identity. > > > > > >-Prashanth > > > > > > > > >On 5/2/14 3:25 PM, "internet-drafts@ietf.org" > > > > > >wrote: > > > > > >> > > >>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt > > >>has been successfully submitted by Prashanth Patil and posted to the > > >>IETF repository. > > >> > > >>Name: draft-patil-tram-turn-serv-disc > > >>Revision: 01 > > >>Title: TURN Server Auto Discovery > > >>Document date: 2014-05-02 > > >>Group: Individual Submission > > >>Pages: 11 > > >>URL: > > >>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc- > > >>01 > > >>.tx > > >>t > > >>Status: > > >>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ > > >>Htmlized: > > >>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 > > >>Diff: > > >>http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-01 > > >> > > >>Abstract: > > >> Current Traversal Using Relays around NAT (TURN) server discovery > > >> mechanisms are relatively static and limited to explicit > > >> configuration. These are usually under the administrative control= of > > >> the application or TURN service provider, and not the enterprise o= r > > >> the ISP, the network in which the client is located. Enterprises = and > > >> ISPs wishing to provide their own TURN servers need auto discovery > > >> mechanisms that a TURN client could use with no or minimal > > >> configuration. This document describes two such mechanisms for TU= RN > > >> server discovery. > > >> > > >> > > >> > > >> > > >> > > >>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 > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu May 22 02:29: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 3A57B1A011D for ; Thu, 22 May 2014 02:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] 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 K2L5GYRd3TtI for ; Thu, 22 May 2014 02:29:27 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12321A004E for ; Thu, 22 May 2014 02:29:24 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201405221129197115; Thu, 22 May 2014 11:29:19 +0200 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Prashanth Patil \(praspati\)'" , , "'Simon Perreault'" References: <913383AAA69FF945B8F946018B75898A2433691A@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2433691A@xmb-rcd-x10.cisco.com> Date: Thu, 22 May 2014 11:29:17 +0200 Message-ID: <097c01cf75a0$4e0d8600$ea289200$@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: Ac91GHqR/nbc2tHQT56l8am6h3ZpawAfLj6w Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/shpE-u9C21CD6nLjJgZboBE9rPo Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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, 22 May 2014 09:29:30 -0000 Hi Tiru, you misinterpreted the use case, let me clarify. Because there are restrictive firewalls (or other reasons) that media = cannot get THROUGH (as you report below), as a solution we PARALLEL that = firewall with a TURN server having one LAN and one WAN interface, where the TURN server at the LAN interface is offered to the enterprise LAN users to be used without further authentication. This is (part of) use case "3.3.5. Simple Video Communication Service, enterprise aspects" in = draft-ietf-rtcweb-use-cases-and-requirements-14.txt : "TURN server that straddles" ... "It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN = servers. This should be possible to achieve by auto-configuration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application." Resulting in requirement: F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). And in the enterprise case discussed, you don't expect the enterprise to advertise that LAN TURN server with more than one (simple to configure) method, do you? - Anycast method: Just add a route in the existing restrictive firewall/router - DHCP method: Add the TURN servers LAN IP-Address to a local DHCP = server (which may be available in the existing restrictive firewall. - DNS stuff: Set up something more complex on the LAN My questions - or rather wanting to hear your thoughts - that maybe = should be spelled out in the draft: In this case, isn't advertizing by the Anycast-method (always?) = sufficient? If using other methods - browsers of course MUST use all methods for discovery. Let us hear your thoughts/considerations. (Including, what should go into some webrtc-draft how browsers use the = auto discovery in your draft.) /Karl -----Ursprungligt meddelande----- Fr=E5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 21 maj 2014 19:17 Till: Karl Stahl; Prashanth Patil (praspati); tram@ietf.org; 'Simon Perreault' =C4mne: RE: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > Sent: Tuesday, May 20, 2014 6:06 PM > To: Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati);=20 > tram@ietf.org; 'Simon Perreault' > Subject: Re: [tram] New Version Notification for=20 > draft-patil-tram-turn-serv-disc- 01.txt >=20 > In this multiple methods discussion, what about this WebRTC use case=20 > that I think will be common: >=20 > An enterprise installs a TURN server with one LAN-port (paralleling=20 > its firewall), because it wants to use WebRTC but maintain a=20 > restrictive firewall policy, that stops WebRTC media or it wants to=20 > have a better media path than through his ordinary data crowded = Internet access. > > Would it then be sufficient to add a route in its ordinary firewall,=20 > so the anycast- address goes to that local TURN-server - and the=20 > Web-browsers really use that path? >=20 > I don't see the enterprise wanting to set up other discovery methods = also. Enterprise firewall policies to permit WebRTC media and data channels is = an interesting problem it was discussed in pntaw ietf mailing list sometime back. Various mechanisms like http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideration= s-0 3, PCP etc were discussed. As far as I remember there was no conclusion = that only anycast approach would work.=20 Cheers, -Tiru >=20 > /Karl >=20 >=20 > -----Ursprungligt meddelande----- > Fr=E5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Skickat: den 20 maj 2014 09:14 > Till: Karl Stahl; Prashanth Patil (praspati); tram@ietf.org; 'Simon Perreault' > =C4mne: RE: [tram] New Version Notification for=20 > draft-patil-tram-turn-serv-disc- 01.txt >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > > Sent: Tuesday, May 20, 2014 3:58 AM > > To: Prashanth Patil (praspati); tram@ietf.org; 'Simon Perreault' > > Subject: Re: [tram] New Version Notification for > > draft-patil-tram-turn-serv-disc- 01.txt > > > > I read "We'll probably need both if we want to maximize chances of=20 > > discovery." in the draft also, but don't really get it. >=20 > With Secure DHCPv6 with Public Key > http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02, DHCP has=20 > benefits over Anycast. > But since DHCP is not workable in some cases, clients may end-up using = > both the techniques (for e.g. use happy-eyeball mechanism) and give=20 > precedence to TURN server learnt using secure DHCP. >=20 > > > > Do you mean that if the network provider offers one particular TURN=20 > > server to his network users, that TURN server should be advertised=20 > > in both suggested ways? >=20 > Yes >=20 > -Tiru >=20 > By maximize, the draft really means discovering servers that may not=20 > support all discoverable methods. For example, if a provider already=20 > has TURN application service provisioned in DNS (as in RFC5928), it=20 > can be readily discovered without needing anycast. >=20 > -Prashanth >=20 > > > > /Karl > > > > -----Ursprungligt meddelande----- > > Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil > > (praspati) > > Skickat: den 19 maj 2014 20:12 > > Till: Karl Stahl; tram@ietf.org; 'Simon Perreault' > > =C4mne: Re: [tram] New Version Notification for=20 > > draft-patil-tram-turn-serv-disc-01.txt > > > > Hi Karl, > > > > On 5/18/14 6:13 PM, "Karl Stahl" wrote: > > > > >I browsed through this document and to me it looks mature enough to = > > >be pushed forward (hopefully soon) to get an IANA anycast address=20 > > >etc., so these things can be put into current WebRTC browsers. As=20 > > >we know, many enterprises cannot use WebRTC at all today due to=20 > > >their restrictive firewall policies - they need a TURN server on=20 > > >their LAN, discovered and used by the WebRTC browsers to even begin using WebRTC. > > > > > >However, I raised a few questions and some suggestions=20 > > >http://www.ietf.org/mail-archive/web/tram/current/msg00480.html > > >at the end of the previous version of this draft that never became=20 > > >discussed and remain: > > > > > >A) Under 8.2 there is a suggested way to assure that the TURN=20 > > >server returned by the anycast method, is provided by the network=20 > > >provider (and not some far away TURN server that should not be=20 > > >trusted to use without authentication): "... can set an IP TTL on=20 > > >their TURN requests that limits how far they can travel into the = public Internet." > > > > > >I suggest that this TTL limitation is specified (e.g. Don't look=20 > > >further than 3 steps - local firewall + max 2 ISP routers) and=20 > > >brought into section "5. Discovery using Anycast" of the draft. > > > > I think the decision should be left up to the application. We could, = > > maybe, make a recommendation at best (i.e. it is not a MUST). > > > > > > > > > >B) Shall we really have more than one method? If the Anycast method = > > >can be used by everyone, why then also have DHCP and now a two more > methods? > > > > There are essentially 2 methods described in the draft (1) Service=20 > > resolution and (2) Anycast. We'll probably need both if we want to=20 > > maximize chances of discovery. > > DHCP happens to be one method to obtain the domain-name for (1)=20 > > Service resolution. While the DHCP method may not workable in some=20 > > cases, the other two methods (one of them inspired by > > draft-kist-alto-3pdisc) could offer better results. We can do away=20 > > with > DHCP, if that is the WG consensus. > > > > > > > > > >I assume you intend that all webrtc browsers implement and can use=20 > > >all methods? Or? (If a service provider e.g. deploys DHCP=20 > > >discovered TURN servers, but some webrtc browser in some operating=20 > > >system don't find/cannot use the TURN server, it would be bad.) > > > > > >In previous discussions, there were some fears that DHCP options=20 > > >are not available in some common OSs. If so, I think the DHCP=20 > > >method should be skipped. > > > > > >Also, if the other methods (other than anycast) may fail, why have them? > > > > Anycast may fail, too. > > > > > > > > > >Are they better to deploy and provision for network service = providers? > > > > > >And will webrtc browsers implement all these methods? > > > > > >Do we have input/feedback on these questions? > > > > > >Should the "connect speed factor" not also be considered? Even=20 > > >though the auto discovery can be done in advance of a call, we=20 > > >should consider the mobility use case. With a mobile client=20 > > >changing network, LAN/LTE/public WiFi etc., we want to get up and=20 > > >run as soon as possible, so the auto discovery of a new TURN server = > > >should not be a tedious process > > > > > >And should the quick anycast auto discovery not be the first to be=20 > > >tried/used (which it is not now in the draft)? > > > > Given that there is a service resolution mechanism for TURN over=20 > > DTLS=20 > > (http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it seems useful to do service resolution before. > > > > > > > >C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery > > >is now RFC7216. > > > > Thanks, will update. > > > > -Prashanth > > > > > > > > > >/Karl > > > > > > > > >-----Ursprungligt meddelande----- > > >Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil > > >(praspati) > > >Skickat: den 2 maj 2014 12:02 > > >Till: tram@ietf.org > > >=C4mne: [tram] FW: New Version Notification for=20 > > >draft-patil-tram-turn-serv-disc-01.txt > > > > > >A new revision of the TURN server discovery draft has been = published. > > >Notable updates : > > > > > >* 300 (Try Alternate) response for anycast. > > >* Mechanism described in draft-kist-alto-3pdisc i.e. using the=20 > > >clients own address to populate the DNS reverse zone (i.e.,=20 > > >in-addr.arpa or > > >ip6.arpa) with appropriate NAPTR records pointing to the TURN = server. > > >* Learning domain names from own identity. > > > > > >-Prashanth > > > > > > > > >On 5/2/14 3:25 PM, "internet-drafts@ietf.org" > > > > > >wrote: > > > > > >> > > >>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt > > >>has been successfully submitted by Prashanth Patil and posted to=20 > > >>the IETF repository. > > >> > > >>Name: draft-patil-tram-turn-serv-disc > > >>Revision: 01 > > >>Title: TURN Server Auto Discovery > > >>Document date: 2014-05-02 > > >>Group: Individual Submission > > >>Pages: 11 > > >>URL: > > >>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-dis > > >>c- > > >>01 > > >>.tx > > >>t > > >>Status: > > >>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ > > >>Htmlized: > > >>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 > > >>Diff: > > = >>http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-0 > > >>1 > > >> > > >>Abstract: > > >> Current Traversal Using Relays around NAT (TURN) server = discovery > > >> mechanisms are relatively static and limited to explicit > > >> configuration. These are usually under the administrative = control of > > >> the application or TURN service provider, and not the = enterprise or > > >> the ISP, the network in which the client is located. = Enterprises and > > >> ISPs wishing to provide their own TURN servers need auto = discovery > > >> mechanisms that a TURN client could use with no or minimal > > >> configuration. This document describes two such mechanisms for TURN > > >> server discovery. > > >> > > >> > > >> > > >> > > >> > > >>Please note that it may take a couple of minutes from the time of=20 > > >>submission until the htmlized version and diff are available at=20 > > >>tools.ietf.org. > > >> > > >>The IETF Secretariat > > >> > > > > > >_______________________________________________ > > >tram mailing list > > >tram@ietf.org > > >https://www.ietf.org/mailman/listinfo/tram > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri May 23 01:45: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 6644D1A03D6 for ; Fri, 23 May 2014 01:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Pj86fieAwJ-a for ; Fri, 23 May 2014 01:45:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B28C1A03CB for ; Fri, 23 May 2014 01:45:23 -0700 (PDT) X-AuditID: c1b4fb2d-f79ed6d000003d40-9c-537f0aa0e79f Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E6.97.15680.0AA0F735; Fri, 23 May 2014 10:45:21 +0200 (CEST) Received: from [131.160.126.248] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.174.1; Fri, 23 May 2014 10:45:20 +0200 Message-ID: <537F0A9F.1090401@ericsson.com> Date: Fri, 23 May 2014 11:45:19 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3RnchV32wweIKiw9rL7A5MHosWfKT KYAxissmJTUnsyy1SN8ugSvjwcFnbAW/GCsef5zF1sB4krGLkZNDQsBEYsPjCcwQtpjEhXvr 2boYuTiEBI4ySuzYe4oFwlnLKPGio40FpIpXQFvi66m7bCA2i4CqxMTr21hBbDYBC4ktt+6D 1YgKREns6vvFDlEvKHFy5hOwuIiAsMTcg3fBbGEBA4k9r2YD1XAAbRaX6GkMAgkzC+hJTLna wghhy0tsfzsH7DghoLXLn7WwTGDkn4Vk6iwkLbOQtCxgZF7FKFqcWlycm25krJdalJlcXJyf p5eXWrKJERhoB7f81t3BuPq14yFGAQ5GJR7eB0x1wUKsiWXFlbmHGKU5WJTEeS9pVAcLCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYPT/sGDxrU13S5fq7zvIv3cT6y+3V9NcIu1yvvR1zmPI OzE/zlim8ZSofdfRP9oCNg1i08WTYlfM5b7Zu96s+tg13cLw0I7XOjE7NydqnDPu/vDw749T Z3/1/TjW79XrsOGiZUbpP+dJs9+6W2cZ32lfsP2AT0uc74TMo2smHq9217t3ULco6aMSS3FG oqEWc1FxIgARWG2CFQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Dqk8t6pPSbtFxXdJI95EvGasju4 Subject: [tram] WGLC: draft-ietf-tram-auth-problems-01 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, 23 May 2014 08:45:26 -0000 Folks, we are starting a Working Group Last Call (WGLC) on the following draft: http://datatracker.ietf.org/doc/draft-ietf-tram-auth-problems/ This WGLC will end on June 6th. Please, send your comments to this list. Thanks, Gonzalo From nobody Fri May 23 05:12: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 79EC71A0181 for ; Fri, 23 May 2014 05:12:18 -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 Pmar1mmEdvwd for ; Fri, 23 May 2014 05:12:15 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D891A0177 for ; Fri, 23 May 2014 05:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14419; q=dns/txt; s=iport; t=1400847134; x=1402056734; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=miJaV/Aw3OBXRy+dN6Ya8qhi64Zo+ioaJPRFNBW1TQk=; b=BnNNWflKoliwGi64NviSUwX0fibeczB3wzhGS5X+tbwtnIRbzt52XavD zd5wURYVuQjt0bwOsX+qgJ+kk9kgHsoSBcCQFED2xScHvR+iL/6AS5GSa iSPAPPj+31fAr4CT+AbIDgVZasBrlXMESLvODhg4WJSagrgNXFXB4rxA+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoIAJ86f1OtJA2N/2dsb2JhbABQCYMHUlEHvQiHPAGBCRZ0giUBAQEDAQEBAWoBCQcHBgEIEQQBAQEKHS4LFAkJAQQBEggBEogeCAgF11oXiTOERAMHAQEeMwuDJYEVBIlnkUiRaoM4bYEBCRci X-IronPort-AV: E=Sophos;i="4.98,893,1392163200"; d="scan'208";a="327368343" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP; 23 May 2014 12:12:12 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4NCCC7v025207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 May 2014 12:12:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 23 May 2014 07:12:12 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Karl Stahl , "Prashanth Patil (praspati)" , "tram@ietf.org" , "'Simon Perreault'" Thread-Topic: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt Thread-Index: Ac92gDOVw9oothYRQZui0FBNf1c9ng== Date: Fri, 23 May 2014 12:12:11 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24337770@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.58.189] 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/XHegn_tfiF2iR3L2DLqs8-o8phI Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-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, 23 May 2014 12:12:18 -0000 > -----Original Message----- > From: Karl Stahl [mailto:karl.stahl@intertex.se] > Sent: Thursday, May 22, 2014 2:59 PM > To: Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); tram@ietf.o= rg; > 'Simon Perreault' > Subject: SV: [tram] New Version Notification for draft-patil-tram-turn-se= rv-disc- > 01.txt >=20 > Hi Tiru, you misinterpreted the use case, let me clarify. >=20 > Because there are restrictive firewalls (or other reasons) that media can= not > get THROUGH (as you report below), as a solution we PARALLEL that firewal= l > with a TURN server having one LAN and one WAN interface, where the TURN > server at the LAN interface is offered to the enterprise LAN users to be > used without further authentication. >=20 > This is (part of) use case "3.3.5. Simple Video Communication Service, > enterprise aspects" in draft-ietf-rtcweb-use-cases-and-requirements-14.tx= t : > "TURN server that straddles" ... "It must be possible to configure the > browsers used in the enterprise with network specific STUN and TURN serve= rs. > This should be possible to achieve by auto-configuration methods. The > RTCWEB functionality will need to utilize both network specific STUN and > TURN resources and STUN and TURN servers provisioned by the web > application." >=20 > Resulting in requirement: > F20 The browser must support the use of STUN and TURN > servers that are supplied by entities other than > the web application (i.e. the network provider). >=20 > And in the enterprise case discussed, you don't expect the enterprise to > advertise that LAN TURN server with more than one (simple to configure) > method, do you? > - Anycast method: Just add a route in the existing restrictive > firewall/router > - DHCP method: Add the TURN servers LAN IP-Address to a local DHCP server > (which may be available in the existing restrictive firewall. > - DNS stuff: Set up something more complex on the LAN >=20 > My questions - or rather wanting to hear your thoughts - that maybe shoul= d > be spelled out in the draft: >=20 > In this case, isn't advertizing by the Anycast-method (always?) sufficien= t? Looks sufficient for this use case only. Please note that this is not the o= nly use case for TURN server usage in Enterprise deployment. The other poss= ible scenario is that Enterprise has tie-up with third party TURN service p= rovider. For more information refer to the Introduction in draft http://too= ls.ietf.org/html/draft-williams-peer-redirect-00. In this case TURN servers= are discovered using DNS and Enterprise Firewall would be configured to pe= rmit UDP traffic to these third party TURN servers only. -Tiru > If using other methods - browsers of course MUST use all methods for > discovery. >=20 > Let us hear your thoughts/considerations. > (Including, what should go into some webrtc-draft how browsers use the au= to > discovery in your draft.) >=20 > /Karl >=20 > -----Ursprungligt meddelande----- > Fr=E5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Skickat: den 21 maj 2014 19:17 > Till: Karl Stahl; Prashanth Patil (praspati); tram@ietf.org; 'Simon > Perreault' > =C4mne: RE: [tram] New Version Notification for > draft-patil-tram-turn-serv-disc-01.txt >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > > Sent: Tuesday, May 20, 2014 6:06 PM > > To: Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); > > tram@ietf.org; 'Simon Perreault' > > Subject: Re: [tram] New Version Notification for > > draft-patil-tram-turn-serv-disc- 01.txt > > > > In this multiple methods discussion, what about this WebRTC use case > > that I think will be common: > > > > An enterprise installs a TURN server with one LAN-port (paralleling > > its firewall), because it wants to use WebRTC but maintain a > > restrictive firewall policy, that stops WebRTC media or it wants to > > have a better media path than through his ordinary data crowded Interne= t > access. > > > > Would it then be sufficient to add a route in its ordinary firewall, > > so the anycast- address goes to that local TURN-server - and the > > Web-browsers really use that path? > > > > I don't see the enterprise wanting to set up other discovery methods al= so. >=20 > Enterprise firewall policies to permit WebRTC media and data channels is = an > interesting problem it was discussed in pntaw ietf mailing list sometime > back. Various mechanisms like > http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideration= s-0 > 3, PCP etc were discussed. As far as I remember there was no conclusion t= hat > only anycast approach would work. >=20 > Cheers, > -Tiru >=20 > > > > /Karl > > > > > > -----Ursprungligt meddelande----- > > Fr=E5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > > Skickat: den 20 maj 2014 09:14 > > Till: Karl Stahl; Prashanth Patil (praspati); tram@ietf.org; 'Simon > Perreault' > > =C4mne: RE: [tram] New Version Notification for > > draft-patil-tram-turn-serv-disc- 01.txt > > > > > -----Original Message----- > > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > > > Sent: Tuesday, May 20, 2014 3:58 AM > > > To: Prashanth Patil (praspati); tram@ietf.org; 'Simon Perreault' > > > Subject: Re: [tram] New Version Notification for > > > draft-patil-tram-turn-serv-disc- 01.txt > > > > > > I read "We'll probably need both if we want to maximize chances of > > > discovery." in the draft also, but don't really get it. > > > > With Secure DHCPv6 with Public Key > > http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02, DHCP has > > benefits over Anycast. > > But since DHCP is not workable in some cases, clients may end-up using > > both the techniques (for e.g. use happy-eyeball mechanism) and give > > precedence to TURN server learnt using secure DHCP. > > > > > > > > Do you mean that if the network provider offers one particular TURN > > > server to his network users, that TURN server should be advertised > > > in both suggested ways? > > > > Yes > > > > -Tiru > > > > By maximize, the draft really means discovering servers that may not > > support all discoverable methods. For example, if a provider already > > has TURN application service provisioned in DNS (as in RFC5928), it > > can be readily discovered without needing anycast. > > > > -Prashanth > > > > > > > > /Karl > > > > > > -----Ursprungligt meddelande----- > > > Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil > > > (praspati) > > > Skickat: den 19 maj 2014 20:12 > > > Till: Karl Stahl; tram@ietf.org; 'Simon Perreault' > > > =C4mne: Re: [tram] New Version Notification for > > > draft-patil-tram-turn-serv-disc-01.txt > > > > > > Hi Karl, > > > > > > On 5/18/14 6:13 PM, "Karl Stahl" wrote: > > > > > > >I browsed through this document and to me it looks mature enough to > > > >be pushed forward (hopefully soon) to get an IANA anycast address > > > >etc., so these things can be put into current WebRTC browsers. As > > > >we know, many enterprises cannot use WebRTC at all today due to > > > >their restrictive firewall policies - they need a TURN server on > > > >their LAN, discovered and used by the WebRTC browsers to even begin > using WebRTC. > > > > > > > >However, I raised a few questions and some suggestions > > > >http://www.ietf.org/mail-archive/web/tram/current/msg00480.html > > > >at the end of the previous version of this draft that never became > > > >discussed and remain: > > > > > > > >A) Under 8.2 there is a suggested way to assure that the TURN > > > >server returned by the anycast method, is provided by the network > > > >provider (and not some far away TURN server that should not be > > > >trusted to use without authentication): "... can set an IP TTL on > > > >their TURN requests that limits how far they can travel into the pub= lic > Internet." > > > > > > > >I suggest that this TTL limitation is specified (e.g. Don't look > > > >further than 3 steps - local firewall + max 2 ISP routers) and > > > >brought into section "5. Discovery using Anycast" of the draft. > > > > > > I think the decision should be left up to the application. We could, > > > maybe, make a recommendation at best (i.e. it is not a MUST). > > > > > > > > > > > > > >B) Shall we really have more than one method? If the Anycast method > > > >can be used by everyone, why then also have DHCP and now a two more > > methods? > > > > > > There are essentially 2 methods described in the draft (1) Service > > > resolution and (2) Anycast. We'll probably need both if we want to > > > maximize chances of discovery. > > > DHCP happens to be one method to obtain the domain-name for (1) > > > Service resolution. While the DHCP method may not workable in some > > > cases, the other two methods (one of them inspired by > > > draft-kist-alto-3pdisc) could offer better results. We can do away > > > with > > DHCP, if that is the WG consensus. > > > > > > > > > > > > > >I assume you intend that all webrtc browsers implement and can use > > > >all methods? Or? (If a service provider e.g. deploys DHCP > > > >discovered TURN servers, but some webrtc browser in some operating > > > >system don't find/cannot use the TURN server, it would be bad.) > > > > > > > >In previous discussions, there were some fears that DHCP options > > > >are not available in some common OSs. If so, I think the DHCP > > > >method should be skipped. > > > > > > > >Also, if the other methods (other than anycast) may fail, why have > them? > > > > > > Anycast may fail, too. > > > > > > > > > > > > > >Are they better to deploy and provision for network service provider= s? > > > > > > > >And will webrtc browsers implement all these methods? > > > > > > > >Do we have input/feedback on these questions? > > > > > > > >Should the "connect speed factor" not also be considered? Even > > > >though the auto discovery can be done in advance of a call, we > > > >should consider the mobility use case. With a mobile client > > > >changing network, LAN/LTE/public WiFi etc., we want to get up and > > > >run as soon as possible, so the auto discovery of a new TURN server > > > >should not be a tedious process > > > > > > > >And should the quick anycast auto discovery not be the first to be > > > >tried/used (which it is not now in the draft)? > > > > > > Given that there is a service resolution mechanism for TURN over > > > DTLS > > > (http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it > seems useful to do service resolution before. > > > > > > > > > > >C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery > > > >is now RFC7216. > > > > > > Thanks, will update. > > > > > > -Prashanth > > > > > > > > > > > > > >/Karl > > > > > > > > > > > >-----Ursprungligt meddelande----- > > > >Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Prashanth Patil > > > >(praspati) > > > >Skickat: den 2 maj 2014 12:02 > > > >Till: tram@ietf.org > > > >=C4mne: [tram] FW: New Version Notification for > > > >draft-patil-tram-turn-serv-disc-01.txt > > > > > > > >A new revision of the TURN server discovery draft has been published= . > > > >Notable updates : > > > > > > > >* 300 (Try Alternate) response for anycast. > > > >* Mechanism described in draft-kist-alto-3pdisc i.e. using the > > > >clients own address to populate the DNS reverse zone (i.e., > > > >in-addr.arpa or > > > >ip6.arpa) with appropriate NAPTR records pointing to the TURN server= . > > > >* Learning domain names from own identity. > > > > > > > >-Prashanth > > > > > > > > > > > >On 5/2/14 3:25 PM, "internet-drafts@ietf.org" > > > > > > > >wrote: > > > > > > > >> > > > >>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt > > > >>has been successfully submitted by Prashanth Patil and posted to > > > >>the IETF repository. > > > >> > > > >>Name: draft-patil-tram-turn-serv-disc > > > >>Revision: 01 > > > >>Title: TURN Server Auto Discovery > > > >>Document date: 2014-05-02 > > > >>Group: Individual Submission > > > >>Pages: 11 > > > >>URL: > > > >>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-dis > > > >>c- > > > >>01 > > > >>.tx > > > >>t > > > >>Status: > > > >>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ > > > >>Htmlized: > > > >>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 > > > >>Diff: > > > >>http://www.ietf.org/rfcdiff?url2=3Ddraft-patil-tram-turn-serv-disc-= 0 > > > >>1 > > > >> > > > >>Abstract: > > > >> Current Traversal Using Relays around NAT (TURN) server discover= y > > > >> mechanisms are relatively static and limited to explicit > > > >> configuration. These are usually under the administrative contr= ol > of > > > >> the application or TURN service provider, and not the enterprise= or > > > >> the ISP, the network in which the client is located. Enterprise= s > and > > > >> ISPs wishing to provide their own TURN servers need auto discove= ry > > > >> mechanisms that a TURN client could use with no or minimal > > > >> configuration. This document describes two such mechanisms for > TURN > > > >> server discovery. > > > >> > > > >> > > > >> > > > >> > > > >> > > > >>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 > > > > > > > > > > _______________________________________________ > > > 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 Sun May 25 23:26: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 ABE751A023D for ; Sun, 25 May 2014 23:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.302 X-Spam-Level: X-Spam-Status: No, score=-102.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 JI5y5GnSpPI2 for ; Sun, 25 May 2014 23:26:43 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14481A0495 for ; Sun, 25 May 2014 23:26:41 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-f8-5382de9d8f01 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 03.38.25910.D9ED2835; Mon, 26 May 2014 08:26:37 +0200 (CEST) Received: from [131.160.126.198] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.174.1; Mon, 26 May 2014 08:26:36 +0200 Message-ID: <5382DE9C.2040303@ericsson.com> Date: Mon, 26 May 2014 09:26:36 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stach, Thomas" , "draft-ietf-tram-stun-dtls@tools.ietf.org" References: <53688A4D.8050208@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvje7ce03BBn2TtS2eTTK1OLlzG7PF h7UX2ByYPZYs+cnk8eXyZzaP7T2PWQKYo7hsUlJzMstSi/TtErgyvrS3MhacVaiYNHczawPj DckuRk4OCQETiQkn/7FA2GISF+6tZ+ti5OIQEjjKKDFt6nlWCGcto8TKL+fYQap4BbQl/t5v ZwKxWQRUJS7s3McMYrMJWEhsuXUfbJKoQJTErr5fUPWCEidnPgGLiwi0M0p8aU8HsZkFlCV2 zF0KViMs4CBxo+MKG4gtJJAnMf9mKyOIzSngL/Fx5Uqg+RxA14lL9DQGQbTqSUy52sIIYctL NG+dzQzRqi2x/FkLywRGoVlINs9C0jILScsCRuZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWb GIGBfXDLb4MdjC+fOx5iFOBgVOLhfZDeFCzEmlhWXJl7iFGag0VJnPeiRnWwkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsb4ZzG1p554f5yicJqh9KmMXd6UVg2OEh9F0ThF3Zgf+9785ts/ PV19qkp8jM2x76/+r/+dqPLXLUTpmv0/dheveEEpxZagaE5n/SiVu+Kbvs1/EvIg/M+9CqZl MsYdwe/lavsmfvDtcPFveZvXbnvp89y3j6q71rIuFZ94rfhde1Rm68QmByWW4oxEQy3mouJE AOXF70lNAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tram/i9Fp93TRiPzpQqfRq_btRnVpgsg Cc: "tram@ietf.org" Subject: Re: [tram] WGLC: draft-ietf-tram-stun-dtls-02 - review 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, 26 May 2014 06:26:46 -0000 Hi Thomas, thanks for your comments. The authors will revise the draft in order to address them. Cheers, Gonzalo On 20/05/2014 5:53 PM, Stach, Thomas wrote: > Marc, Gonzalo, > > I did a review of your draft and, though the draft is in good shape, > I came across some points which were not clear to me. > > Section 3 DTLS as Transport for STUN > ... > STUN over DTLS MUST, at a minimum, > support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support > TLS_RSA_WITH_AES_128_CBC_SHA. > > The first MUST is qualified with "at a minimum". > Should that indicate that the second MUST is not really a MUST? > If not, then you might want to remove "at a minimum". > If yes, use RECOMMENDED for TLS_RSA_WITH_AES_128_CBC_SHA. > > The STUN over TLS default cipher suite was TLS_RSA_WITH_AES_128_CBC_SHA. > Are both cipher suites above meant as addition to the TLS default or as a replacement? > I propose to clarify either with > "In addition to TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher suite for STUN over TLS, STUN over DTLS implementation MUST support ." > or > "Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher suite for STUN over TLS, STUN over DTLS implementation MUST support ." > > Section 4. STUN Usages > The link in "[RFC5389] Section 7.2 ." points to section 7.2 of this draft. > Similar links in the draft point directly to the relevant RFC. > You may want to change this link accordingly. > > Section 4.1 NAT Discovery Usage > ... > Regardless, this usage is rarely used by itself, since TURN [RFC5766] > is generally mandatory to use with ICE [RFC5245], and TURN provides > the same NAT Discovery feature as part of an Allocation creation. In > fact, with ICE, the NAT Discovery usage is only used when there is no > longer any resource available for new Allocations in the TURN server. > > TURN support is not mandated in RFC5245, it is only at SHOULD strength. > See http://tools.ietf.org/html/rfc5245#section-4.1.1.2. > The easiest fix is probably to remove that whole paragraph. > > 4.2. Connectivity Check Usage > .. > This usage MUST NOT be used with a STUN URI. > It is not obvious to me what is meant here. > Do you want say that connectivity checks MUST NOT be sent over DTLS? > MUST NOT is maybe a bit strong, but I would not object violently. > > 4.3. Media Keep-Alive Usage > The media keep-alive (described in Section 20 of [RFC5245]) runs > inside an RTP or RTCP session, so it is already protected if the RTP > or RTCP session is also protected (i.e., SRTP/SRTCP). Adding DTLS > inside the SRTP/SRTCP session would add overhead, with minimal > security benefit. > > This usage MUST NOT be used with a STUN URI. > > I think the first sentence is a bit misleading. Media keep alive is separate from the RTP or SRTP session. > The STUN Binding indications are just multiplexed on the same port as (S)RTP/(S)RTCP. > Sending the STUN Binding indication in DTLS records would however change how this multiplexing is done, and as stated, would add overhead and initially some delay. > Again I can't parse "This usage MUST NOT be used with a STUN URI." > Do you mean "STUN Binding indications MUST NOT be sent over DTLS"? > > 4.4. SIP Keep-Alive Usage > . > This usage MUST NOT be used with a STUN URI. > As above it is not clear to me what is meant. > > > Kind Regards/mit freundlichen Grüßen > Thomas Stach > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: Dienstag, 6. Mai 2014 09:08 >> To: tram@ietf.org >> Subject: [tram] WGLC: draft-ietf-tram-stun-dtls-02 >> >> Folks, >> >> we are starting a Working Group Last Call (WGLC) on the following draft: >> >> http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ >> >> This WGLC will end on May 21st. Please, send your comments to this list. >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram From nobody Mon May 26 10:44:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE561A01F5 for ; Mon, 26 May 2014 10:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 JeYzaI3oom_I for ; Mon, 26 May 2014 10:44:22 -0700 (PDT) Received: from nomis80.org (nomis80.org [IPv6:2600:3c03::f03c:91ff:fe69:7108]) by ietfa.amsl.com (Postfix) with ESMTP id BBE161A01EE for ; Mon, 26 May 2014 10:44:22 -0700 (PDT) Received: from [IPv6:2001:470:1d:bc0:5585:6b49:9d1d:e74c] (unknown [IPv6:2001:470:1d:bc0:5585:6b49:9d1d:e74c]) by nomis80.org (Postfix) with ESMTPSA id E26B61D1002 for ; Mon, 26 May 2014 17:45:49 +0000 (UTC) Message-ID: <53837D72.9090902@per.reau.lt> Date: Mon, 26 May 2014 13:44:18 -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" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PKU6zvwB2QnlQyDaS8e0VcgQHyk Subject: [tram] DTLS: should it update RFC7064? 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, 26 May 2014 17:44:24 -0000 This text in draft-ietf-tram-stun-dtls-02 section 4.1.1 struck me as potentially requiring an "Updates: 7064" mention in the header: 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. Yay or nay? Simon From nobody Fri May 30 02:52: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 4E07B1A07B2 for ; Fri, 30 May 2014 02:52:44 -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 uIi1f5YXvmUL for ; Fri, 30 May 2014 02:52:42 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5999D1A03D6 for ; Fri, 30 May 2014 02:52:42 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id to1so1503076ieb.2 for ; Fri, 30 May 2014 02:52:38 -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=Ze7/WteHFmz33OZGzdJJtHDISBpFk7K+Ki6MprvJeLk=; b=Dv+TC3liafDkAcNl0Ezaz34z+AEFYOpOi4WBISWb/0FinDymiTZ+yqCOhzOFZwmKtc 2J0ONcK0+HuUf18R8FV+DLjIdbwbmfeNOm7YZzQ/DNOYWtC8cmmTi7Jd/ilDTQ0u2/9S wZgYg5akrTV4jR1c+RG5KIkDeI+Hw41VLY9T0= 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=Ze7/WteHFmz33OZGzdJJtHDISBpFk7K+Ki6MprvJeLk=; b=mdRdaNpYTz0iU9xFlqeGXTGqsVpDK8ZOhy1VNAhjVieeyqH0YE9uV/OvhWBdBQaA+Q jiBAS8qukj0tV+WXptvd0GQDxG2bphlGCKjxu7fRNS3Xa6V3KyYdz/2C7p3SHPgsjki1 pFAYMi1kP9H0Mm+qq97H0ZYv1+90R9Qrt2Xit/pI93o7bh21vW5W7k7wwkacMeJ40bnn o2b1COcQEVpCPNtTHnVko2vLGMc+29xT1S7xe7byglUVlFEVsui4wcKyqiRgnJanajHu vQEZEXULz3AseWYKO8wyTXYr76fZBQC+kiaMSfCMHnXtOdWuePay21u0akqm6e6QTnUC aHvg== X-Gm-Message-State: ALoCoQlDdoNXaT6QWtvNV/TgAEOBt5kAwaWhs1MqV/T6gPi6189/f/XaPFVkXXpcu47jhVcYfV5P X-Received: by 10.50.87.102 with SMTP id w6mr3969615igz.31.1401443557923; Fri, 30 May 2014 02:52:37 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id v8sm4330645igk.16.2014.05.30.02.52.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 02:52:36 -0700 (PDT) Message-ID: <538854DE.1010609@getjive.com> Date: Fri, 30 May 2014 03:52:30 -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: Simon Perreault , "tram@ietf.org" References: <53837D72.9090902@per.reau.lt> In-Reply-To: <53837D72.9090902@per.reau.lt> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HeUHFI7VgKe8p78djCtHADH0q7od6Gosg" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/AZB8lb_DaW5VRTdsRugH_uIHRqo Subject: Re: [tram] DTLS: should it update RFC7064? 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, 30 May 2014 09:52:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HeUHFI7VgKe8p78djCtHADH0q7od6Gosg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Simon, Sorry, I missed this email. On 5/26/14, 11:44 AM, Simon Perreault wrote: > This text in draft-ietf-tram-stun-dtls-02 section 4.1.1 struck me as > potentially requiring an "Updates: 7064" mention in the header: >=20 > 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 a= n > 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. >=20 > Yay or nay? >=20 I do not think so. We do not change the fact that a STUN (or TURN) URI can contain an IP address, we simply state that when used to establish a (D)TLS connection to a STUN/TURN server, an URI containing an IP address must be rejected (unless a domain name can be provided in parallel). This said, on the subject of Updates, a case can be made to have this draft updating RFC 5928 and probably also RFC 5389 (early versions of the draft had these). --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --HeUHFI7VgKe8p78djCtHADH0q7od6Gosg 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/ iQEcBAEBAgAGBQJTiFTjAAoJEMUNRP98lsiXw2YH/2/82+AOTIHYvVneJ+vBNmfh o/wiWYaKvYRLl9rnFLEWwRZlrEiC/0spWNCrdufQbrMMwxBW50tu+LUJTv3TtDcL J4tjOb0UkWAuAospbndsPK2LkiAM2oiD0TDWRlhjzo3Q0pYxGu9Etv47+rMgNU8V C/h1Kq+UE81H+M+c2HSdiwuTPnqqPy4EpZIT493HUtI3OBNNwd/xZ2ToTqGNgY7k sE9Y7lCpRPckQ2OeObQIKrFI0AcFD1fFsImr75yIohEZMFtWWvTDrDZLtlnjCa+L AUBwkUthRuOUfLDeSKzMqwt9cE0NzLHQOIVJhYWM5BeW7ET/hGKcaUn5+YLuSAE= =OPnb -----END PGP SIGNATURE----- --HeUHFI7VgKe8p78djCtHADH0q7od6Gosg-- From nobody Fri May 30 09:32: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 9A7811A08F1 for ; Fri, 30 May 2014 09:32:55 -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 sITYGlewpuHL for ; Fri, 30 May 2014 09:32:53 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BCC1A035B for ; Fri, 30 May 2014 09:32:53 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so1040228igd.2 for ; Fri, 30 May 2014 09:32:49 -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:cc:subject :references:in-reply-to:content-type; bh=dC9ON4MJJusPgYMY77iOy1LSV9fN+OacdIrqKmeDG0o=; b=NbBuklJrATwX3cwwKpAiPUpCIT5M9bSoHyT5IzmJokJ+UaZUFESmCAvv77Y4uKQf/q L8S1ew8YgQNayWcL5uYaDGSD2CmjlPF2Z/w4lK8OKO4SH4Mv2xroQJPhCJNlu1BGU7NG VUMJGsnHxQTuXLeYlqGfvIAKeq/xrwBf4aDpI= 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 :cc:subject:references:in-reply-to:content-type; bh=dC9ON4MJJusPgYMY77iOy1LSV9fN+OacdIrqKmeDG0o=; b=mU1QUUqUcbMvEaeCb0HJ7B6Y/mVQ3niheeGBNeBwBZWIivrh1fItcJhvL0NsRVsibW J1EqprJ/p6iPQmei3iydULIrBes1PSjwHVvkp/5QXIq3M5G4F7Z3RtOZTbpH0fwZeAoD 2osS7RGvxKOlU3FkHZXPn3mY0vUOJVQUr3gQZFcGswlKD2qacife9zQkhnv1D06h7F4W +JWG0D8ZMpk9ZxkdNzNzJZ59ojeJ30vaO5wG6Oqf2SLPW0FF1FlR5X0Bnbkw0IXFA50G 08NmMMxejSC9tf+k2E1ZrhlrrZcOMV5SmHw/A5XU6kYPu7Kag25Y1YiWvDOoX8W3fKys omqQ== X-Gm-Message-State: ALoCoQnIrIKM2BV3rsMxzRGgi2SNFA3+VOodsrO+MYea19WDt1YWhVfMnYe3Cz5XkbgXG2llijnQ X-Received: by 10.50.66.143 with SMTP id f15mr7422300igt.18.1401467569110; Fri, 30 May 2014 09:32:49 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id t18sm6543673igr.18.2014.05.30.09.32.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 09:32:48 -0700 (PDT) Message-ID: <5388B2AE.4030200@getjive.com> Date: Fri, 30 May 2014 10:32:46 -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: "Stach, Thomas" , "draft-ietf-tram-stun-dtls@tools.ietf.org" References: <53688A4D.8050208@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kwvHMbHinwVen0XAAlexJd5UeoFld1AK7" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/JprgC_9Sa5SfUzaj4kmLmoAnE88 Cc: Gonzalo Camarillo , "tram@ietf.org" Subject: Re: [tram] WGLC: draft-ietf-tram-stun-dtls-02 - review 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, 30 May 2014 16:32:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kwvHMbHinwVen0XAAlexJd5UeoFld1AK7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, Thank you for the review, and sorry for the delay in responding. Please see my answers inline. On 5/20/14, 8:53 AM, Stach, Thomas wrote: > Marc, Gonzalo, >=20 > I did a review of your draft and, though the draft is in good shape,=20 > I came across some points which were not clear to me. >=20 > Section 3 DTLS as Transport for STUN > ... > STUN over DTLS MUST, at a minimum, > support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support > TLS_RSA_WITH_AES_128_CBC_SHA. =20 >=20 > The first MUST is qualified with "at a minimum". > Should that indicate that the second MUST is not really a MUST?=20 > If not, then you might want to remove "at a minimum". > If yes, use RECOMMENDED for TLS_RSA_WITH_AES_128_CBC_SHA. I think that the intent was "at a minimum both of them", but I agree that the text is confusing. Fixed in the new version. >=20 > The STUN over TLS default cipher suite was TLS_RSA_WITH_AES_128_CBC_SHA= =2E=20 > Are both cipher suites above meant as addition to the TLS default or as= a replacement? The latter. > I propose to clarify either with > "In addition to TLS_RSA_WITH_AES_128_CBC_SHA, which is the default ciph= er suite for STUN over TLS, STUN over DTLS implementation MUST support ."= > or > "Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher s= uite for STUN over TLS, STUN over DTLS implementation MUST support ." Text added. >=20 > Section 4. STUN Usages > The link in "[RFC5389] Section 7.2 ." points to section 7.2 of this dra= ft.=20 > Similar links in the draft point directly to the relevant RFC.=20 > You may want to change this link accordingly. I suppose that this is an artifact of the HTMLization of the I-D but as editors we do not have any control on this, as far as I know. >=20 > Section 4.1 NAT Discovery Usage > ... > Regardless, this usage is rarely used by itself, since TURN [RFC5766= ] > is generally mandatory to use with ICE [RFC5245], and TURN provides > the same NAT Discovery feature as part of an Allocation creation. I= n > fact, with ICE, the NAT Discovery usage is only used when there is n= o > longer any resource available for new Allocations in the TURN server= =2E >=20 > TURN support is not mandated in RFC5245, it is only at SHOULD strength.= =20 > See http://tools.ietf.org/html/rfc5245#section-4.1.1.2. =20 > The easiest fix is probably to remove that whole paragraph. "mandatory" here meant "it is a disservice to your customers to not use TURN" more than "the IETF forces you to use TURN". I replaced "since TURN is generally mandatory to use" by "since using TURN with ICE is generally indispensable". >=20 > 4.2. Connectivity Check Usage > ..=20 > This usage MUST NOT be used with a STUN URI. > It is not obvious to me what is meant here.=20 > Do you want say that connectivity checks MUST NOT be sent over DTLS? > MUST NOT is maybe a bit strong, but I would not object violently. No it means that STUN URI must not be used with this usage, so we do not have to specify how STUN URI are to be interpreted in this context. Changed the text to: "STUN URIs are not used with this usage." >=20 > 4.3. Media Keep-Alive Usage > The media keep-alive (described in Section 20 of [RFC5245]) runs > inside an RTP or RTCP session, so it is already protected if the RTP= > or RTCP session is also protected (i.e., SRTP/SRTCP). Adding DTLS > inside the SRTP/SRTCP session would add overhead, with minimal > security benefit. >=20 > This usage MUST NOT be used with a STUN URI. >=20 > I think the first sentence is a bit misleading. Media keep alive is sep= arate from the RTP or SRTP session.=20 > The STUN Binding indications are just multiplexed on the same port as (= S)RTP/(S)RTCP.=20 Yes, you are right. I shorten the sentence to "The media keep-alive (described in Section 10 of [RFC5245]) runs alongside an RTP or RTCP session." > Sending the STUN Binding indication in DTLS records would however chang= e how this multiplexing is done, and as stated, would add overhead and in= itially some delay.=20 RFC 5764 already permits that kind of multiplexing but it also forbids using application_data records, so a non-srtp additional session would have to be negotiated, at the cost of additional delay. So the new text says that: "It is possible to send the media keep-alive packets inside a separately negotiated non-srtp DTLS session if DTLS-SRTP [RFC5764] is used, but that would add overhead, with minimal security benefit." > Again I can't parse "This usage MUST NOT be used with a STUN URI."=20 > Do you mean "STUN Binding indications MUST NOT be sent over DTLS"? See above. >=20 > 4.4. SIP Keep-Alive Usage > . > This usage MUST NOT be used with a STUN URI. > As above it is not clear to me what is meant. See above. >=20 >=20 > Kind Regards/mit freundlichen Gr=FC=DFen > Thomas Stach >=20 >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo Camaril= lo >> Sent: Dienstag, 6. Mai 2014 09:08 >> To: tram@ietf.org >> Subject: [tram] WGLC: draft-ietf-tram-stun-dtls-02 >> >> Folks, >> >> we are starting a Working Group Last Call (WGLC) on the following draf= t: >> >> http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ >> >> This WGLC will end on May 21st. Please, send your comments to this lis= t. >> >> Thanks, >> >> Gonzalo >> --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --kwvHMbHinwVen0XAAlexJd5UeoFld1AK7 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/ iQEcBAEBAgAGBQJTiLKuAAoJEMUNRP98lsiX5jAH/0Tc0891gbvcEmzdTSYDkl0q lQ7eqEHOePh5uMfO8tXYLHZ5ZXmapeOxR45oSZ5/cbcf7fvV0KcRJW7tluum3C6Y Y6EOZpeWvnfGqRQNzJNq5DC0UdQqCagGQCgc5zy2g8WOtqAYewKNTfAvpgzKigH+ uVJ7EKYOBnyO1TVvLiSmYNFOl/Cbh8uE+B3lEABQYuHXDAg/UdxmfigEQ7lRiHIH ELKeROsOJF7mTJqixmNew04XFtmbkAWjS3G94Y3v6HrXJYJKSSkQczb3nXlnxARP MO6VQUI7VHAiKpGD01GpUY48yQAeUEV5zWu4iNQrJT39bnhFr7uZFX5264fGd74= =UooH -----END PGP SIGNATURE----- --kwvHMbHinwVen0XAAlexJd5UeoFld1AK7-- From nobody Fri May 30 09:36: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 3B0C91A0985; Fri, 30 May 2014 09:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 t6inMVJFjqYx; Fri, 30 May 2014 09:36:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1758E1A018F; Fri, 30 May 2014 09:36:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140530163625.18998.88986.idtracker@ietfa.amsl.com> Date: Fri, 30 May 2014 09:36:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/3hQlqcu7TrbrE_jAJoIco0GAx_0 Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-dtls-03.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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, 30 May 2014 16:36:26 -0000 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-03.txt Pages : 16 Date : 2014-05-30 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-dtls-03 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/