From nobody Mon Jul 6 08:37:55 2015 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 065EA1B2C8F; Mon, 6 Jul 2015 08:37:53 -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 SPGoZlTm6RZl; Mon, 6 Jul 2015 08:37:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B1A1B2C42; Mon, 6 Jul 2015 08:37:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706153751.19540.5274.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 08:37:51 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turnbis-05.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: Mon, 06 Jul 2015 15:37:53 -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 : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-05.txt Pages : 77 Date : 2015-07-06 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turnbis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-05 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 Mon Jul 6 08:43:12 2015 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 E8E4F1B2D43 for ; Mon, 6 Jul 2015 08:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWAnz1LnaNGh for ; Mon, 6 Jul 2015 08:43:08 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644BC1B2D42 for ; Mon, 6 Jul 2015 08:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2749; q=dns/txt; s=iport; t=1436197388; x=1437406988; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rSJ4JX9TemdpznWZ48gEchdntzrNYsfu/BAlE+CzHl0=; b=iorYZXnnJkQHFr9WjJdOhDj8H1kC4TwhrSuXusdYcUsKsdmvm3kf3HGe P0j5XbRif9FY41GhndoKLOgFYrW+L9I/ji2Rxrl6Vux0IPY2E2/39V9mh f93dkeoBaphn0ze0IQtCfuQepc1aw+Xfrq7pibNwKfLcxEzToqx7/dXKh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CpAwDloJpV/5RdJa1cgxJUYAa9VgmBZAqFdwKBMzgUAQEBAQEBAYEKhCMBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIiCYNyysBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0uEOxo4BoMRgRQFlBUBhGGIQESDUZMHJoN7b4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,415,1432598400"; d="scan'208";a="165826739" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 06 Jul 2015 15:43:07 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t66Fh71s012718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Jul 2015 15:43:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.123]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 10:43:07 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-05.txt Thread-Index: AQHQuAHC0vPrC9M/EkmU/tx1xTC7k53Ok5BA Date: Mon, 6 Jul 2015 15:43:06 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47886BC9@xmb-rcd-x10.cisco.com> References: <20150706153751.19540.5274.idtracker@ietfa.amsl.com> In-Reply-To: <20150706153751.19540.5274.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.56.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-05.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, 06 Jul 2015 15:43:10 -0000 This revision adds TURN URI scheme and uses https://tools.ietf.org/html/dra= ft-ietf-tram-turn-server-discovery-03 to discover TURN servers.=20 Cheers, -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, July 06, 2015 9:08 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-05.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 : Traversal Using Relays around NAT (TURN): Relay= Extensions > to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-05.txt > Pages : 77 > Date : 2015-07-06 >=20 > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. >=20 > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-turnbis-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-05 >=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 Mon Jul 6 12:35:42 2015 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 916411B30C8 for ; Mon, 6 Jul 2015 12:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHCYXsjRxeSF for ; Mon, 6 Jul 2015 12:35:40 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE721B30C4 for ; Mon, 6 Jul 2015 12:35:39 -0700 (PDT) Received: by iecuq6 with SMTP id uq6so120267166iec.2 for ; Mon, 06 Jul 2015 12:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6IIYS3juzbszYd2aE5tRWkId3ubplvV0bZ9Ql4GUPIk=; b=AW7lTqRymvbKAvc0Nc+qUt7XyWc8SQ7gLwynO4hnNA2g9tJ/C/r/qtCqVJ2+cjnk4I Veu0AlMIDbGdwooS7aeYHENf7oqA+oBscPhhGSpmsWf1yHLJ65kaVN6Q3F2Z0JdkSNdK bj7hPrMsy/q73zypxhr+lewuVH7dy+DVOVLz71+yJs2UiAVumysFkbx4sskyRB3nor/P X8BUop0CAh2EKUopXx9MuEqPI04tcw0obotKYYI9QoedHvCAhAOwvjiWq2pT0Ue3kdU9 sXtp1E2Mb4jR833Web3Am12m9TMBQ0AVI9XTTiPCIJ61IcklnZsNKZvI4B2xQbFiH8Wy NpDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6IIYS3juzbszYd2aE5tRWkId3ubplvV0bZ9Ql4GUPIk=; b=Cpbl4x48CxeeqeTm0ow82/gh3b/y06wPiXeMSrSf5MR0mzoMz/lINmYVn3LifMmltT ccLLmMYHjIofh4tGWkT/WDF6RN8lG5ZszZtqov+swdY+nvCBwCxoZIuBAhDTZzT3LNU5 Z5QHwwUkDw97wrxuFNhRbGe0P1WrXDvIp5ixDJc+3Gi/dnS6KRRBLd+068qOc0u6f0fD JP/2W+6jELrOxtM6qV68+qUP8eViOCdIKo4+HhrhzLOelsoW5PSMIqDSl7nKLEa1/1Tc I9NWl5AGE8k9zbnkhAq1/tQ7l8c41PhSH41gyDDmqVc55W1HTWlN2iSrMSAvT9hRiDu8 WrMA== X-Gm-Message-State: ALoCoQlZNsYJpRxhe256bEeJSCbCrgrkrvx1kppjpbAmbcGFqfmZie8oKQfYRHzTsDfYLsRnaGg/ X-Received: by 10.50.4.41 with SMTP id h9mr31302979igh.10.1436211338278; Mon, 06 Jul 2015 12:35:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Mon, 6 Jul 2015 12:35:18 -0700 (PDT) In-Reply-To: <558DA52D.9000408@jive.com> References: <558DA52D.9000408@jive.com> From: Justin Uberti Date: Mon, 6 Jul 2015 15:35:18 -0400 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c31528a447ba051a3a0200 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] TRAM agenda requests 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, 06 Jul 2015 19:35:41 -0000 --001a11c31528a447ba051a3a0200 Content-Type: text/plain; charset=UTF-8 It would be good to mention the restrictions on auto-discovery that were incorporated into the most recent version of RETURN. Specifically, the new security considerations: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00#section-7. Probably only need 5-10 minutes. On Fri, Jun 26, 2015 at 3:17 PM, Simon Perreault wrote: > TRAMsters, > > We have a two-hour slot at IETF 93 in Prague. If you would like to be on > the agenda, please send your request to >. > > Thanks, > Simon & Gonzalo > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c31528a447ba051a3a0200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would be good to mention the restrictions on auto-disco= very that were incorporated into the most recent version of RETURN. Specifi= cally, the new security considerations:=C2=A0https://t= ools.ietf.org/html/draft-ietf-rtcweb-return-00#section-7.

Probably only need 5-10 minutes.

On Fri, Jun 26, 2015 at 3:17 PM, Simon Perreault <= span dir=3D"ltr"><sperreault@jive.com> wrote:
TRAMsters,

We have a two-hour slot at IETF 93 in Prague. If you would like to be on the agenda, please send your request to <mailto:tram-chairs@tools.ietf.org>.=

Thanks,
Simon & Gonzalo

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

--001a11c31528a447ba051a3a0200-- From nobody Mon Jul 6 13:22:14 2015 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 069CA1B31B7 for ; Mon, 6 Jul 2015 13:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 QDOhZdDXgrXd for ; Mon, 6 Jul 2015 13:22:11 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62451B31B5 for ; Mon, 6 Jul 2015 13:22:11 -0700 (PDT) Received: by oihr66 with SMTP id r66so70564303oih.2 for ; Mon, 06 Jul 2015 13:22:11 -0700 (PDT) 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 :content-transfer-encoding; bh=3hPQdJYawmpsLIyAyhSLajXiQu5Xhmj/MyInMvwU8wE=; b=BHOE5NGb3XyaiZosofqG7OzEHGvIg4EedoXLEQBfq03wXXkjwfL7P0XtwT9RDMZSlN jVRuPgtlggDPMOg+TGaBs8EuIf8r49ecwoxeJhsoSYQZPlsqaKBsU+Yxd+3qxC+oc+k7 wOGaGWpcCyTE85kW1WB8yqa1cBhpCDT5ktnowOp/YjHDlErHe05azIcPmQnO7bmc0rME rZz7SMvrSUxX4dhGgPMOJiYhnttVwHpJa4o/D7NWvWUsm/Wnfm4yYzalUlfsg6G1Yuok 2iLefwZQR9Qqrw2h9msYLTtzDSs4AiC6YcaaJDuppaeMQfeN6F+phFCK9x4F3QluXA1c aHJg== X-Gm-Message-State: ALoCoQlHImhnP7u0BVUu7Cc7WJCXXRSEUorth2ek8Nvd1YTu8BlOV12+iI/toZaJkefgjSdcyrCE X-Received: by 10.202.231.129 with SMTP id e123mr571612oih.134.1436214130903; Mon, 06 Jul 2015 13:22:10 -0700 (PDT) Received: from [192.168.1.44] ([24.53.47.130]) by mx.google.com with ESMTPSA id oj1sm10549464oeb.6.2015.07.06.13.22.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 13:22:09 -0700 (PDT) Message-ID: <559AE36F.9020506@jive.com> Date: Mon, 06 Jul 2015 16:22:07 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Justin Uberti References: <558DA52D.9000408@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] TRAM agenda requests 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, 06 Jul 2015 20:22:13 -0000 Le 2015-07-06 15:35, Justin Uberti a écrit : > It would be good to mention the restrictions on auto-discovery that were > incorporated into the most recent version of RETURN. Specifically, the > new security > considerations: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00#section-7. > > Probably only need 5-10 minutes. Added to the Tuesday slot. http://www.ietf.org/proceedings/93/agenda/agenda-93-tram Simon From nobody Tue Jul 7 08:50:51 2015 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 1B48F1A0122 for ; Tue, 7 Jul 2015 08:50:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bFDNVdpDl_u3 for ; Tue, 7 Jul 2015 08:50:48 -0700 (PDT) Received: from smtp112.ord1c.emailsrvr.com (smtp112.ord1c.emailsrvr.com [108.166.43.112]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4283E1ACD97 for ; Tue, 7 Jul 2015 08:50:06 -0700 (PDT) Received: from smtp15.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A40B03801A5 for ; Tue, 7 Jul 2015 11:50:05 -0400 (EDT) Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 50CF53800B4 for ; Tue, 7 Jul 2015 11:50:05 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 07 Jul 2015 15:50:05 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1083A7AC-8DA5-4DF3-962A-E4D074E29204@iii.ca> Date: Tue, 7 Jul 2015 09:50:04 -0600 To: tram@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [tram] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:50:50 -0000 draft-jennings-behave-rtcweb-firewall-00 discussed how firewalls might = handle WebRTC traffic.=20 Would it be possible to get a short amount of agenda time in TRAM to = talk about the changes this draft proposes to some TRAM drafts. = Specifically the issue is when to use the STUN ORIGIN attribute.=20 Thanks, Cullen From nobody Tue Jul 7 09:05:57 2015 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 3AB971ACD9B for ; Tue, 7 Jul 2015 09:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 oNfknd1qunWs for ; Tue, 7 Jul 2015 09:05:55 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243A41A8A04 for ; Tue, 7 Jul 2015 09:05:55 -0700 (PDT) Received: by igau2 with SMTP id u2so40449480iga.0 for ; Tue, 07 Jul 2015 09:05:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TsTvrlFSujaXzwj2WePFBqqoxwdLxSShpcqHpgS60qM=; b=m4BoLD7gSn7KxU6UpDhjAp+fKVZXxLzrdiycSDUjtC2RVG8+A1X1YQaQN+tCCj1yjo fWPOuRD6Gim+xTyMcWxycaC70te0CTBJY5vwvuHJivYEad2labF3AXWqaSzUFqA/8t8e BUMJjOFIgzirVnKlt0VaiKtP1XjPf56/Loa++6YEHTPrJoxyxL7iR/stAvznm0EwbB53 DneDsDXCP/QIScCA8cUG6QFdiwkD5tQvVASkrzBDcc55c8l1m1S6nYzlc8Nmb83OMkj/ 67tD8HSdlTFN2KUucYgBzbtYTJTbuLHoUzccCGqO9j8Cz2CyFSgO0rBGDlc+O/agC08i H2Eg== X-Gm-Message-State: ALoCoQmHqv20rqD7nG/yhMzHpqNJTqbOT4i8gVH3V2NtyFP1oYMsvT+HJEML2qanyG9upnnX45qI X-Received: by 10.50.4.41 with SMTP id h9mr38005664igh.10.1436285154605; Tue, 07 Jul 2015 09:05:54 -0700 (PDT) Received: from Simons-MacBook-Air.local ([24.53.47.130]) by mx.google.com with ESMTPSA id x83sm14882580ioi.6.2015.07.07.09.05.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 09:05:52 -0700 (PDT) Message-ID: <559BF8DE.1050802@jive.com> Date: Tue, 07 Jul 2015 12:05:50 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Cullen Jennings , tram@ietf.org References: <1083A7AC-8DA5-4DF3-962A-E4D074E29204@iii.ca> In-Reply-To: <1083A7AC-8DA5-4DF3-962A-E4D074E29204@iii.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 16:05:56 -0000 Le 2015-07-07 11:50, Cullen Jennings a écrit : > draft-jennings-behave-rtcweb-firewall-00 discussed how firewalls might handle WebRTC traffic. behave, the zombie WG that still gets -00 drafts! ;) > Would it be possible to get a short amount of agenda time in TRAM to talk about the changes this draft proposes to some TRAM drafts. Specifically the issue is when to use the STUN ORIGIN attribute. Sure. Note that ORIGIN has been stopped by the IESG brick wall and will probably need to change significantly. We have scheduled a discussion on that topic as our first order of business. Simon From nobody Tue Jul 7 20:43:02 2015 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 0CDAB1B2E1C for ; Tue, 7 Jul 2015 20:43:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Vy6oop_-Kibx for ; Tue, 7 Jul 2015 20:43:00 -0700 (PDT) Received: from smtp112.iad3a.emailsrvr.com (smtp112.iad3a.emailsrvr.com [173.203.187.112]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD31B1B2DFF for ; Tue, 7 Jul 2015 20:42:59 -0700 (PDT) Received: from smtp7.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DA0BC18045D; Tue, 7 Jul 2015 23:42:58 -0400 (EDT) Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4CB4A180476; Tue, 7 Jul 2015 23:42:58 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Wed, 08 Jul 2015 03:42:58 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Cullen Jennings In-Reply-To: <559BF8DE.1050802@jive.com> Date: Tue, 7 Jul 2015 21:42:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1083A7AC-8DA5-4DF3-962A-E4D074E29204@iii.ca> <559BF8DE.1050802@jive.com> To: Simon Perreault X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tram@ietf.org Subject: Re: [tram] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 03:43:01 -0000 > On Jul 7, 2015, at 10:05 AM, Simon Perreault = wrote: >=20 > Le 2015-07-07 11:50, Cullen Jennings a =E9crit : >> draft-jennings-behave-rtcweb-firewall-00 discussed how firewalls = might handle WebRTC traffic.=20 >=20 > behave, the zombie WG that still gets -00 drafts! ;) >=20 >> Would it be possible to get a short amount of agenda time in TRAM to = talk about the changes this draft proposes to some TRAM drafts. = Specifically the issue is when to use the STUN ORIGIN attribute.=20 >=20 > Sure. >=20 > Note that ORIGIN has been stopped by the IESG brick wall and will > probably need to change significantly. We have scheduled a discussion = on > that topic as our first order of business. >=20 > Simon Thanks - basically this draft is tired up the same issue so it may be = that after that discussion, this draft turns into a very short = discussion. From nobody Mon Jul 13 15:32:11 2015 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 BE3B01A7035 for ; Mon, 13 Jul 2015 15:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_K7Ez-tzlDk for ; Mon, 13 Jul 2015 15:32:06 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2951A7032 for ; Mon, 13 Jul 2015 15:32:04 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201507140032039297; Tue, 14 Jul 2015 00:32:03 +0200 From: "Karl Stahl" To: "'Cullen Jennings'" , "'Simon Perreault'" References: <1083A7AC-8DA5-4DF3-962A-E4D074E29204@iii.ca> <559BF8DE.1050802@jive.com> In-Reply-To: Date: Tue, 14 Jul 2015 00:32:06 +0200 Message-ID: <00a701d0bdbb$bf823560$3e86a020$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01D0BDCC.830B0560" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdC5MDOoRouqSCW6SX+6AfzgpoO5UAEiymmA Content-Language: sv Archived-At: Cc: tram@ietf.org Subject: Re: [tram] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 22:32:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01D0BDCC.830B0560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This and next email was just posted on the RTCWEB list, but concerns = TRAM also: =20 I have read this draft and the latest draft-ietf-rtcweb-return-00 and draft-ietf-tram-turn-server-discovery-03 drafts from the point of view = of finally getting a good and working solution to the old NAT/Firewall traversal issue with real-time communication, here specifically WebRTC = using ICE. =20 I find all these drafts to be in the right direction and should be = worked trough to RFCs. =20 Regarding the comment on Section 6 (=93The IETF is designing systems to = send interactive audio and video such that it looks like HTTPS and HTTP to = the proxies and firewalls =93) and below: > extremely unlikely that we would implement it. =20 I hope this means that the IETF should go no further in the direction of =93fooling real-time traffic=94 through firewalls, but rather make RFCs = that can allows good traversal of real-time traffic for users on networks that = want such traffic, and that we realize: =20 i) The network administrator wanting to block or make real-time traffic = bad and useless can always do that (exemplified in this behave draft, but = maybe the intent has to be clarified). And that taking further steps in the direction of =93fooling real-time traffic=94 through firewalls =93has = some risk of impacting normal HTTP traffic, so there is a desire to provide guidance around ways to do that in this draft.=94 (quote from this behave draft) =20 ii) There may be legitimate reasons to e.g. allow surfing, but not voice = on a network. We cannot/should not rule against that, even if we all are = for net neutrality and against evil purposes for blocking e.g. voice and SIP (which still sometimes seem to be the case). The network admin and the firewall are in charge. If we want to use good real-time communication, = we have to use networks that wants to provide it =96 It should be a selling feature for using the network access. Our efforts could possibly be = advice how evil blocking could be exposed/displayed so users can select other network accesses for real-time communication. =20 I have lost track of where these repeatedly popping up suggestions to = =93fool real-time traffic=94 through the most restrictive firewalls are, but the = only real solution is to make these firewalls less restrictive or to parallel them, which is what the RETURN + TURN server DISCOVERY draft may achieve = in a good way. =20 I think there could be (maybe is) consensus around this, and as a = comment to this behave draft=94: - Yes, it guides how a firewall could be less restrictive, but still = pretty secure, and allow STUN-based traversal of WebRTC real-time traffic = through the network default gateway. =20 However, that is not sufficient, it should in its =93guidance to = firewall vendors=94 (which I believe the draft is), also point out the firewall traversal clarified in the RETURN draft (From the introduction): =93This TURN server may be placed inside the network, with a firewall configuration allowing it to communicate with the public internet, or it may be operated by a third party outside the network, with a firewall configuration that allows hosts inside the network to communicate with it. Use of the specified TURN server may be the only way for clients on the network to achieve a high quality WebRTC experience. This scenario is required to be supported by the WebRTC requirements document [I-D.ietf-rtcweb-use-cases-and-requirements] Section 3.3.5.1.=94 =20 A firewall (designed to be secure AND to handle real-time communication without having to be paralleled by an SBC or a TURN server) could very = well include such TURN server (or TURN Proxy or Border TURN server as it is called in the RETURN draft). =20 Also, a network service provider offering such (sealed) TURN server (or = TURN Proxy or Border TURN server), typically has an enterprise firewall in = front of it: The firewall vendor should then be adviced to recommend his = customers to open a pinhole from the LAN to that TURN server (not to use an own additional border TURN server requiring double RETURN or something like that). =20 So, I suggest to add guidance about these things to this behave draft. =20 =20 Having expressed this, I believe the sealed, configuration and authentication concept of the RETURN draft, and possible the DISCOVERY = draft needs to be clarified/extended, which will follow in next email. =20 /Karl =20 =20 -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Cullen Jennings Skickat: den 8 juli 2015 05:43 Till: Simon Perreault Kopia: tram@ietf.org =C4mne: Re: [tram] Agenda time for = draft-jennings-behave-rtcweb-firewall-00 ? =20 =20 > On Jul 7, 2015, at 10:05 AM, Simon Perreault < sperreault@jive.com> wrote: >=20 > Le 2015-07-07 11:50, Cullen Jennings a =E9crit : >> draft-jennings-behave-rtcweb-firewall-00 discussed how firewalls = might handle WebRTC traffic.=20 >=20 > behave, the zombie WG that still gets -00 drafts! ;) >=20 >> Would it be possible to get a short amount of agenda time in TRAM to = talk about the changes this draft proposes to some TRAM drafts. Specifically = the issue is when to use the STUN ORIGIN attribute.=20 >=20 > Sure. >=20 > Note that ORIGIN has been stopped by the IESG brick wall and will=20 > probably need to change significantly. We have scheduled a discussion=20 > on that topic as our first order of business. >=20 > Simon =20 Thanks - basically this draft is tired up the same issue so it may be = that after that discussion, this draft turns into a very short discussion. =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram ------=_NextPart_000_00A8_01D0BDCC.830B0560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This and next email was just posted on the RTCWEB list, but = concerns TRAM also:

 

I = have read this draft and the latest draft-ietf-rt= cweb-return-00 and = draft-ietf-tram-turn-server-discovery-03 drafts from the point of view of finally getting a = good and working solution to the old NAT/Firewall traversal issue with = real-time communication, here specifically WebRTC using = ICE.

 

I = find all these drafts to be in the right direction and should be worked = trough to RFCs.

 

Re= garding the comment on Section 6 (“The IETF is designing systems to = send interactive audio and video such that it looks like HTTPS and HTTP = to the proxies and firewalls = “) and below:

&g= t; extremely unlikely that we would implement = it.

 

I = hope this means that the IETF should go no further in the direction of = “fooling real-time traffic” through firewalls, but rather = make RFCs that can allows good traversal of real-time traffic for users = on networks that want such traffic, and that we = realize:

 

i)= The network administrator wanting to block or make real-time traffic = bad and useless can always do that (exemplified in this behave draft, = but maybe the intent has to be clarified). And that taking further steps = in the direction of “fooling real-time traffic” through = firewalls “has some risk of impacting normal HTTP traffic, so there is a = desire to provide guidance around ways to do that in this = draft.&#= 8221;  (quote from this behave draft)

 

ii= ) There may be legitimate reasons to e.g. allow surfing, but not voice = on a network. We cannot/should not rule against that, even if we all are = for net neutrality and against evil purposes for blocking e.g. voice and = SIP (which still sometimes seem to be the case). The network admin and = the firewall are in charge. If we want to use good real-time = communication, we have to use networks that wants to provide it – = It should be a selling feature for using the network access. Our efforts = could possibly be advice how evil blocking could be exposed/displayed so = users can select other network accesses for real-time = communication.

 

I = have lost track of where these repeatedly popping up suggestions to = “fool real-time traffic” through the most restrictive = firewalls are, but the only real solution is to make these firewalls = less restrictive or to parallel them, which is what the RETURN + TURN = server DISCOVERY draft may achieve in a good = way.

 

I = think there could be (maybe is) consensus around this, and as a comment = to this behave draft”:

- = Yes, it guides how a firewall could be less restrictive, but still = pretty secure, and allow STUN-based traversal of  WebRTC real-time = traffic through the network default gateway.

 

Ho= wever, that is not sufficient, it should in its “guidance to firewall vendors” (wh= ich I believe the draft is), also point out the firewall traversal = clarified in the RETURN draft (From the = introduction):

&#= 8220;This = TURN server may be placed inside the network, with = a

   firewall configuration = allowing it to communicate with the public

   internet, or it may be operated by a third party = outside the network,

   with a = firewall configuration that allows hosts inside the network = to

   communicate with = it.  Use of the specified TURN server may be = the

   only way for clients on = the network to achieve a high quality WebRTC

   experience.  This scenario is required to be = supported by the WebRTC

   requirements document = [I-D.ietf-rtcweb-use-cases-and-requirements]

   Section 3.3.5.1.”

 

A = firewall (designed to be secure AND to handle real-time communication = without having to be paralleled by an SBC or a TURN server) could very = well include such TURN server (or TURN Proxy or Border TURN server as it = is called in the RETURN draft).

 

Al= so, a network service provider offering such (sealed) TURN server (or = TURN Proxy or Border TURN server), typically has an enterprise firewall = in front of it: The firewall vendor should then be adviced to recommend = his customers to open a pinhole from the LAN to that TURN server (not to = use an own additional border TURN server requiring double RETURN or = something like that).

 

So= , I suggest to add guidance about these things to this behave = draft.

 

 

Ha= ving expressed this, I believe the sealed, configuration and = authentication concept of the RETURN draft, and possible the DISCOVERY = draft needs to be clarified/extended, which will follow in next = email.

 

/K= arl

 

 

-----Ursprungligt meddelande-----
Fr=E5n: tram = [mailto:tram-bounces@ietf.org] F=F6r Cullen Jennings
Skickat: den 8 = juli 2015 05:43
Till: Simon Perreault
Kopia: = tram@ietf.org
=C4mne: Re: [tram] Agenda time for = draft-jennings-behave-rtcweb-firewall-00 ?

 

 

> = On Jul 7, 2015, at 10:05 AM, Simon Perreault <sperreault@jive.com> wrote:

> =

> Le 2015-07-07 11:50, Cullen = Jennings a =E9crit :

>> = draft-jennings-behave-rtcweb-firewall-00 discussed how firewalls might = handle WebRTC traffic.

> =

> behave, the zombie WG that = still gets -00 drafts! ;)

> =

>> Would it be possible to = get a short amount of agenda time in TRAM to talk about the changes this = draft proposes to some TRAM drafts. Specifically the issue is when to = use the STUN ORIGIN attribute.

>

> = Sure.

>

> Note that ORIGIN has been stopped by the IESG = brick wall and will

> probably = need to change significantly. We have scheduled a discussion =

> on that topic as our first = order of business.

> =

> Simon

 

Thanks = - basically this draft is tired up the same issue so it may be that = after that discussion, this draft turns into a very short = discussion.

 

 

 

_______________________________________________=

tram mailing list

tram@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/tram

------=_NextPart_000_00A8_01D0BDCC.830B0560-- From nobody Mon Jul 13 15:37:22 2015 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 59ACF1A86E4 for ; Mon, 13 Jul 2015 15:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1] 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 rLhdrnzviiSG for ; Mon, 13 Jul 2015 15:37:19 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5901A854C for ; Mon, 13 Jul 2015 15:37:18 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201507140037179698; Tue, 14 Jul 2015 00:37:17 +0200 From: "Karl Stahl" To: "'Simon Perreault'" , "'Benjamin Schwartz'" References: <20150513222927.5331.57264.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 14 Jul 2015 00:37:20 +0200 Message-ID: <00ac01d0bdbc$7ad9a690$708cf3b0$@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: AQJx3nsi5TPW+CoNulq21Pq7Z6VVFpyXT4XwgABrUmA= Content-Language: sv Archived-At: Cc: tram@ietf.org Subject: Re: [tram] [TRAM] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery: X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 22:37:21 -0000 This and previous email was just posted on the RTCWEB list, but concerns TRAM's DISCOVERY draft also: We need this draft implemented in WebRTC browsers as soon as possible, = so we can get good WebRTC in difficult places (for firewall traversal and for quality). Is there any implementation e.g. in Chrome that can be tried? Now having stated that I am positive to this draft, I have some concerns/questions/suggestions: 1) We need more levels than sealed/leaky It is not acceptable that WebRTC traffic between parties on a typical = LAN is forced through a TURN server, just because of a sealed configuration required for good WebRTC traffic over the WAN. This consequence is = pointed out under "5.11. Reusing the same TURN server", but IS a problem even = if it "work as expected". Such TURN resource consumption, waste of bandwidth and possible = performance degradation do not happen today, and can easily be avoided. I realize this consequence of "sealed" is required to meet some of the requirements under "3.2. Independent Path Control", but we simply need = an "exo-sealed" level, in addition to the proposed strictly sealed and = leaky, allowing local endpoints to connect media directly, while external = traffic is forced to use the TURN server (rather than STUN through the default gateway).=20 Such "exo-sealed" configuration should be the default configuration if a network provided TURN server is made available for good (non-evil) = purposes. 2) Mobile devices need to work on various networks, without individual configuration=20 I am not clear about the thoughts behind the "configuration" of sealed = level and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials = and force a certain sealed level upon the WebRTC-browser when used at that = LAN, or if the user has the possibility to configure manually, I am OK with = that this can and should OVERRIDE any default configuration or other configuration (on that particular network). However, for mobile devices - Don't we all happily connect our browsers = via WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should = be used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network.=20 A network provided TURN-server can easily be made available ONLY to the network users that it is serving, so there is no need for authentication = and credentials to protect against illegal usage of a valuable resource, = like it is with the application provided turn server. Network provided TURN = servers are simply deployed for the network users to be use without other authentication than being granted an IP address and a default gateway to = use on that particular network in itself. The same goes for trusting the TURN server with our real-time traffic - = If we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our network: Data through the default gateway, RTC through the TURN path is why the = TURN server is provided! But do we know that it is not someone with the evil purpose of stealing = our (encrypted!) real time traffic that is offering the TURN server (instead = of the network provider), which leads us to my point 3). (If we really = think there is a risk of and danger with such attacks...) 3) Is it now good enough to simply use the auto discovered TURN server? = Hope so! There has been some recent improvements to draft-ietf-tram-turn-server-discovery-03 and hopefully that is = sufficient for assuming that the auto-discovered TURN server is offered by our = network provider (a service provider or the enterprise itself) that we trust = anyway, and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be leaky.) Some concerns regarding the DISCOVERY draft and whether these things = should be specified in the RETURN document: - Is the above the case with all discovery methods proposed? Or shall = the RETURN document make one method mandatory to implement? - Can that method then be the Anycast method (which by far seems to be = the most convenient to deploy and to implement and should work for all = network types and in all devices operating systems). I think what is said under "9.3. Anycast" under "9. Security Considerations" is sufficient for trusting such discovered TURN server. What should then go into the = RETURN draft - or should the DISCOVERY draft be more specific? I don't fully understand the DISCOVERY draft's: "... three discovery mechanisms. The reason for providing multiple mechanisms is to maximize = the opportunity for discovery," - Can we really put the burden upon all WebRTC devices to implement all methods and I doubt network providers will deploy more than one method. = That seems risking rather than maximizing discovery... It is high time to get this done - can we? /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r = internet-drafts@ietf.org Skickat: den 14 maj 2015 00:29 Till: i-d-announce@ietf.org Kopia: rtcweb@ietf.org =C4mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. Title : Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Authors : Benjamin M. Schwartz Justin Uberti Filename : draft-ietf-rtcweb-return-00.txt Pages : 18 Date : 2015-05-13 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jul 13 18:16:19 2015 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 E970D1A8748 for ; Mon, 13 Jul 2015 18:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Maa6gb5hgckA for ; Mon, 13 Jul 2015 18:16:14 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54DB1A872D for ; Mon, 13 Jul 2015 18:16:13 -0700 (PDT) Received: by ieik3 with SMTP id k3so1504927iei.3 for ; Mon, 13 Jul 2015 18:16:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sSeWqXd3q3befsjZygukZf6WCLXi/YU9MxNMG4zcW1Y=; b=ETQvqgJtAjIyX7PVX6T82Z9/if7N6eZhViNcuQT5BFYbtMh4i6Uc/dBAKb81pr+0OY L0pL3mk9QQDsylHePTUp9cnrJ8ms3GBhVsOWCXCwidob2gBSiV5vUWntXqyTWPahMVsY 2Kc95wH3n7X02Zn2QB/MVm3Mk3/Dn4/LjTQDpTJwqzlSCVKN0Dzt1AdeJDMbYHDkmdZ8 e5pz82Xj3f8vPkD/GmvMFlBv6pcci9RWDxtC1GEJCe1SPJ26MuxIlgQatrYSUqDgKdFW FFZWaA+PTF59vdinnMM/vgz0jQMmzRfMDbzvM0rLnj/Mu4+ZOL7zJwo2SMWF4RUc/nXu vMYw== X-Gm-Message-State: ALoCoQn4GbODGWRV7G4nElJ0167tu6eMzm+ju3p9ET2LdjcefgU8qM9SlHL4/KhAIdgbMczdbmiX X-Received: by 10.107.167.145 with SMTP id q139mr21596523ioe.137.1436836573228; Mon, 13 Jul 2015 18:16:13 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id r95sm5362701ioi.38.2015.07.13.18.16.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2015 18:16:11 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so70969992igc.0 for ; Mon, 13 Jul 2015 18:16:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.7.104 with SMTP id i8mr114418iga.50.1436836570686; Mon, 13 Jul 2015 18:16:10 -0700 (PDT) Received: by 10.64.171.114 with HTTP; Mon, 13 Jul 2015 18:16:10 -0700 (PDT) In-Reply-To: <55a4396c.e525700a.ff81b.11d4SMTPIN_ADDED_BROKEN@mx.google.com> References: <20150513222927.5331.57264.idtracker@ietfa.amsl.com> <55a4396c.e525700a.ff81b.11d4SMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 13 Jul 2015 21:16:10 -0400 Message-ID: From: Benjamin Schwartz To: Karl Stahl Content-Type: multipart/alternative; boundary=089e01183ebc65a076051acb9588 Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [tram] [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery: X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 01:16:18 -0000 --089e01183ebc65a076051acb9588 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl wrote: > We need this draft implemented in WebRTC browsers as soon as possible, so > we > can get good WebRTC in difficult places (for firewall traversal and for > quality). Is there any implementation e.g. in Chrome that can be tried? > > Now having stated that I am positive to this draft, I have some > concerns/questions/suggestions: > > 1) We need more levels than sealed/leaky > > It is not acceptable that WebRTC traffic between parties on a typical LAN > is > forced through a TURN server, just because of a sealed configuration > required for good WebRTC traffic over the WAN. This consequence is pointe= d > out under "5.11. Reusing the same TURN server", but IS a problem even if > it > "work as expected". > > Such TURN resource consumption, waste of bandwidth and possible performan= ce > degradation do not happen today, and can easily be avoided. > > I realize this consequence of "sealed" is required to meet some of the > requirements under "3.2. Independent Path Control", but we simply need a= n > "exo-sealed" level, in addition to the proposed strictly sealed and leaky= , > allowing local endpoints to connect media directly, while external traffi= c > is forced to use the TURN server (rather than STUN through the default > gateway). > How do you propose to tell what is "local"? I don't know how to define that procedurally. I think my main concern here is that it requires us to "lie" to the remote party, by sending candidates that we may then refuse to use even if they work. This seems very strange. Such "exo-sealed" configuration should be the default configuration if a > network provided TURN server is made available for good (non-evil) > purposes. > > > 2) Mobile devices need to work on various networks, without individual > configuration > > I am not clear about the thoughts behind the "configuration" of sealed > level > and requirements for authentication of the turn server, but if there are > methods where an enterprise network (LAN) admin can provide credentials a= nd > force a certain sealed level upon the WebRTC-browser when used at that LA= N, > or if the user has the possibility to configure manually, I am OK with th= at > this can and should OVERRIDE any default configuration or other > configuration (on that particular network). > > However, for mobile devices - Don't we all happily connect our browsers v= ia > WiFi here and there? - there must be a way for a network provider with a > good intent to offer an exo-sealed TURN server that automatically should = be > used, e.g. to achieve the purpose of offering better RTC quality than is > available through the default gateway WAN path on that network. > > A network provided TURN-server can easily be made available ONLY to the > network users that it is serving, so there is no need for authentication > and > credentials to protect against illegal usage of a valuable resource, like > it > is with the application provided turn server. Network provided TURN serve= rs > are simply deployed for the network users to be use without other > authentication than being granted an IP address and a default gateway to > use > on that particular network in itself. > > The same goes for trusting the TURN server with our real-time traffic - I= f > we would trust the same network provider with the same real-time traffic > through the default gateway - we should also use the offered TURN server > without other "authentication" than that it is available on our network: > Data through the default gateway, RTC through the TURN path is why the TU= RN > server is provided! > > But do we know that it is not someone with the evil purpose of stealing o= ur > (encrypted!) real time traffic that is offering the TURN server (instead = of > the network provider), which leads us to my point 3). (If we really think > there is a risk of and danger with such attacks...) > > > 3) Is it now good enough to simply use the auto discovered TURN server? > Hope > so! > > There has been some recent improvements to > draft-ietf-tram-turn-server-discovery-03 and hopefully that is sufficient > for assuming that the auto-discovered TURN server is offered by our netwo= rk > provider (a service provider or the enterprise itself) that we trust > anyway, > and the TURN server then simply shall be used and considered exo-sealed. > (The current RETURN draft says a non configured TURN server should be > leaky.) > The security considerations in that document suggest that not all discovery mechanisms have equal additional exposure to local network interference. I would appreciate clearer guidance on that front. It seems to me that DHCP is the only listed mechanism that creates minimal additional exposure to network interference. > Some concerns regarding the DISCOVERY draft and whether these things shou= ld > be specified in the RETURN document: > > - Is the above the case with all discovery methods proposed? Or shall the > RETURN document make one method mandatory to implement? > > - Can that method then be the Anycast method (which by far seems to be th= e > most convenient to deploy and to implement and should work for all networ= k > types and in all devices operating systems). I think what is said under > "9.3. Anycast" under "9. Security Considerations" is sufficient for > trusting such discovered TURN server. What should then go into the RETURN > draft - or should the DISCOVERY draft be more specific? > > I don't fully understand the DISCOVERY draft's: "... three discovery > mechanisms. The reason for providing multiple mechanisms is to maximize t= he > opportunity for discovery," > > - Can we really put the burden upon all WebRTC devices to implement all > methods and I doubt network providers will deploy more than one method. > That > seems risking rather than maximizing discovery... > > > It is high time to get this done - can we? > > /Karl > > > > > > > > > > -----Ursprungligt meddelande----- > Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r internet-draf= ts@ietf.org > Skickat: den 14 maj 2015 00:29 > Till: i-d-announce@ietf.org > Kopia: rtcweb@ietf.org > =C3=84mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > Title : Recursively Encapsulated TURN (RETURN) for > Connectivity and Privacy in WebRTC > Authors : Benjamin M. Schwartz > Justin Uberti > Filename : draft-ietf-rtcweb-return-00.txt > Pages : 18 > Date : 2015-05-13 > > Abstract: > In the context of WebRTC, the concept of a local TURN proxy has been > suggested, but not reviewed in detail. WebRTC applications are > already using TURN to enhance connectivity and privacy. This > document explains how local TURN proxies and WebRTC applications can > work together. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e01183ebc65a076051acb9588 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 13, 2015 at 6:19 PM, Karl Stahl <karl.stahl@intertex.se&g= t; wrote:
We need this draft imple= mented in WebRTC browsers as soon as possible, so we
can get good WebRTC in difficult places (for firewall traversal and for
quality). Is there any implementation e.g. in Chrome that can be tried?

Now having stated that I am positive to this draft, I have some
concerns/questions/suggestions:

1) We need more levels than sealed/leaky

It is not acceptable that WebRTC traffic between parties on a typical LAN i= s
forced through a TURN server, just because of a sealed configuration
required for good WebRTC traffic over the WAN. This consequence is pointed<= br> out under "5.11.=C2=A0 Reusing the same TURN server", but IS a pr= oblem even if it
"work as expected".

Such TURN resource consumption, waste of bandwidth and possible performance=
degradation do not happen today, and can easily be avoided.

I realize this consequence of "sealed" is required to meet some o= f the
requirements under "3.2.=C2=A0 Independent Path Control", but we = simply need an
"exo-sealed" level, in addition to the proposed strictly sealed a= nd leaky,
allowing local endpoints to connect media directly, while external traffic<= br> is forced to use the TURN server (rather than STUN through the default
gateway).

How do you propose to tell wh= at is "local"?=C2=A0 I don't know how to define that procedur= ally.

I think my main concern here is that it requ= ires us to "lie" to the remote party, by sending candidates that = we may then refuse to use even if they work.=C2=A0 This seems very strange.=

Such "exo-sealed" configuration should be the default configurati= on if a
network provided TURN server is made available for good (non-evil) purposes= .


2) Mobile devices need to work on various networks, without individual
configuration

I am not clear about the thoughts behind the "configuration" of s= ealed level
and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials and=
force a certain sealed level upon the WebRTC-browser when used at that LAN,=
or if the user has the possibility to configure manually, I am OK with that=
this can and should OVERRIDE any default configuration or other
configuration (on that particular network).

However, for mobile devices - Don't we all happily connect our browsers= via
WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should be=
used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network.

A network provided TURN-server can easily be made available ONLY to the
network users that it is serving, so there is no need for authentication an= d
credentials to protect against illegal usage of a valuable resource, like i= t
is with the application provided turn server. Network provided TURN servers=
are simply deployed for the network users to be use without other
authentication than being granted an IP address and a default gateway to us= e
on that particular network in itself.

The same goes for trusting the TURN server with our real-time traffic - If<= br> we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our n= etwork:
Data through the default gateway, RTC through the TURN path is why the TURN=
server is provided!

But do we know that it is not someone with the evil purpose of stealing our=
(encrypted!) real time traffic that is offering the TURN server (instead of=
the network provider), which leads us to my point 3). (If we really think there is a risk of and danger with such attacks...)


3) Is it now good enough to simply use the auto discovered TURN server? Hop= e
so!

There has been some recent improvements to
draft-ietf-tram-turn-server-discovery-03 and hopefully that is sufficient for assuming that the auto-discovered TURN server is offered by our network=
provider (a service provider or the enterprise itself) that we trust anyway= ,
and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be
leaky.)

The security considerations in = that document suggest that not all discovery mechanisms have equal addition= al exposure to local network interference.=C2=A0 I would appreciate clearer= guidance on that front.=C2=A0 It seems to me that DHCP is the only listed = mechanism that creates minimal additional exposure to network interference.=
=C2=A0
Some concerns regarding the DISCOVERY draft and whether these things should=
be specified in the RETURN document:

- Is the above the case with all discovery methods proposed? Or shall the RETURN document make one method mandatory to implement?

- Can that method then be the Anycast method (which by far seems to be the<= br> most convenient to deploy and to implement and should work for all network<= br> types and in all devices operating systems). I think what is said under
"9.3.=C2=A0 Anycast" under "9.=C2=A0 Security Considerations= " is sufficient for
trusting such discovered TURN server. What should then go into the RETURN draft - or should the DISCOVERY draft be more specific?

I don't fully understand the DISCOVERY draft's: "... three dis= covery
mechanisms. The reason for providing multiple mechanisms is to maximize the=
opportunity for discovery,"

- Can we really put the burden upon all WebRTC devices to implement all
methods and I doubt network providers will deploy more than one method. Tha= t
seems risking rather than maximizing discovery...


It is high time to get this done - can we?

/Karl









-----Ursprungligt meddelande-----
Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r internet-drafts@ietf.org
Skickat: den 14 maj 2015 00:29
Till: i-d-announ= ce@ietf.org
Kopia: rtcweb@ietf.org=
=C3=84mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers
Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Recursively Encapsulated TURN (RETURN) for
Connectivity and Privacy in WebRTC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Benj= amin M. Schwartz
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Justin Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-return-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-05-13

Abstract:
=C2=A0 =C2=A0In the context of WebRTC, the concept of a local TURN proxy ha= s been
=C2=A0 =C2=A0suggested, but not reviewed in detail.=C2=A0 WebRTC applicatio= ns are
=C2=A0 =C2=A0already using TURN to enhance connectivity and privacy.=C2=A0 = This
=C2=A0 =C2=A0document explains how local TURN proxies and WebRTC applicatio= ns can
=C2=A0 =C2=A0work together.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-rtcweb-return/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb= -return-00


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

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

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


--089e01183ebc65a076051acb9588-- From nobody Thu Jul 16 20:40:11 2015 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 A69B51ACD7F for ; Thu, 16 Jul 2015 20:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.944 X-Spam-Level: X-Spam-Status: No, score=0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, J_CHICKENPOX_25=0.6, RDNS_NONE=0.793] 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 XxhDI9hxzIXu for ; Thu, 16 Jul 2015 20:40:07 -0700 (PDT) Received: from tsinghua.org.cn (unknown [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6587B1ACC86 for ; Thu, 16 Jul 2015 20:40:07 -0700 (PDT) Received: from ctbriwangaij (unknown [219.142.69.76]) by app1 (Coremail) with SMTP id Z0GX06ArwwGiWKhVpq5BCw==.45810S2; Fri, 17 Jul 2015 09:21:53 +0800 (CST) From: "Aijun Wang" To: Date: Fri, 17 Jul 2015 11:39:49 +0800 Message-ID: <00a701d0c042$43d85550$cb88fff0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdC0dT/monrbfSNcS76RvJoDWXdjHgLxDXZQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06ArwwGiWKhVpq5BCw==.45810S2 X-Coremail-Antispam: 1U3129KBjvJXoWxXw13Ww48Gry7XFykXw43ZFb_yoW5uw1kpa y5W3y3Xwn5Jr4xGa1kGF4UWw1ru395WrZ7AFy8Gry7ua98AF92qFyayF4YkryUZrs5Wa90 qr4avF1DZa45ZrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUojjgDUUUU Archived-At: Cc: =?utf-8?B?J+S7mOaWjCc=?= , "'Liubing \(Leo\)'" Subject: [tram] FW: New Version Notification for draft-wang-tram-turnlite-03.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, 17 Jul 2015 03:40:09 -0000 Hi, all: We updated the draft about lightweight TURN architecture( = http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/), which = feedback mainly the comments from Brandon Williams.=20 Mr.Bing Liu, the co-author of this draft, will make presentation in the = coming Prague meeting, and will also introduce briefly the solution for = the scenarios that clients located in different ISP' domain. We think the TURNLite approach be one alternative solution for solving = the communication between the clients that located in various NAT = devices. It solves naturally the problem that describe in = https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-03, = and can easily integrate the timestamp STUN attribute that describe in = https://tools.ietf.org/html/draft-martinsen-tram-turnbandwidthprobe-00 = to detect the bandwidth and latency between the client and TURN.=20 Due to the TURN Server selection is controlled centrally in TURNLite = architecture, the communication clients can easily switch to another = feasible TURN server simultaneously. The RS(Relay Selector that = described in TURNLite architecture) can also gather dynamically the = communication statistics data from the relay devices and give the better = selection results of TURN server for the coming communication peers. It can also easily solve the concern for "IP address privacy" that = raised in = https://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00 = and "IP mobility" that raised in=20 http://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/.=20 Wish this draft can give all the TRAMer one different viewpoint to solve = the confronting questions. Any comments are welcome. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, July 02, 2015 11:15 AM To: Aijun Wang; Bing Liu; Aijun Wang; Bing Liu Subject: New Version Notification for draft-wang-tram-turnlite-03.txt A new version of I-D, draft-wang-tram-turnlite-03.txt has been = successfully submitted by Aijun Wang and posted to the IETF repository. Name: draft-wang-tram-turnlite Revision: 03 Title: A Lightweight TURN Architecture and Specification (TURN-Lite) Document date: 2015-07-02 Group: Individual Submission Pages: 17 URL: = https://www.ietf.org/internet-drafts/draft-wang-tram-turnlite-03.txt Status: = https://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ Htmlized: https://tools.ietf.org/html/draft-wang-tram-turnlite-03 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-tram-turnlite-03 Abstract: This document proposes a new relay-based NAT traversal architecture called TURN-Lite which could simplify the data communication process between two hosts that locates behind some non-BEHAVE compliant [RFC4787] [RFC5382] NAT devices. The key mechanism in TURN-Lite is the newly defined "Couple" operation (using STUN [RFC5389] message format) which allows the TURN-Lite servers to be easily incorporated into existing CGN devices/CDN nodes which are already deployed within the network in a distributed manner. = =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 Sun Jul 19 11:23:35 2015 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 07FA71B2B8E; Sun, 19 Jul 2015 11:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 4gmB98hOhUKL; Sun, 19 Jul 2015 11:23:24 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BA31B2B85; Sun, 19 Jul 2015 11:23:21 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201507192023215297; Sun, 19 Jul 2015 20:23:21 +0200 From: "Karl Stahl" To: "'Benjamin Schwartz'" , "'Cullen Jennings \(fluffy\)'" References: <20150513222927.5331.57264.idtracker@ietfa.amsl.com> <55a4396c.e525700a.ff81b.11d4SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Sun, 19 Jul 2015 20:23:17 +0200 Message-ID: <021501d0c24f$fbe66650$f3b332f0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0216_01D0C260.BF6F3650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdC90q5fMBdd1XATSX+N/CqPObKYhgC2/Rtw Content-Language: sv Archived-At: Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [tram] [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery: 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, 19 Jul 2015 18:23:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0216_01D0C260.BF6F3650 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Benjamin =E2=80=93 your concern is valid =E2=80=93 I thought exo-sealed = was easy to do in the browser. =20 Below I list a firewall configuration assisted method to address the = TURN server and bandwidth resource consumption problem for local WebRTC = calls when using the sealed configuration. I believe my suggestion also = will meet all security/trust/privacy perspectives and give secure = auto-configuration, so mobile devices can to be used with high-quality = secure WebRTC communication =E2=80=9Ceverywhere you can surf=E2=80=9D = through proper use of Border TURN servers - which must be the (almost = already achieved) purpose of this RETURN draft. =20 After some consideration, to achieve the preferred exo-sealed = configuration, the RETURN drafts already prescribes the best default = configuration: =E2=80=9Cleaky=E2=80=9D ! :-)=20 Explanations inline below --> =20 Below are also some suggestions for inclusion in the drafts: draft-ietf-tram-turn-server-discovery-03 draft-jennings-behave-rtcweb-firewall-00 =20 /Karl =20 PS: Regarding the TURN Origin debate, I don=E2=80=99t have a clear view, = but am I not right in the understanding that: * The purpose of the TURN Origin draft was to reduce the pain of WebRTC = service providers having to deploy network hardware (the Application = Provided TURN server) to get their services used, by allowing the TURN = server to serve many applications (through a third party).=20 - The introduction of Border TURN servers releases WebRTC service = providers of that pain (when commonly deployed) (and also put security = back in the right place) (Until deployed commonly, yes these SPs = unfortunately have this pain to =E2=80=9Cfool their services=E2=80=9D = through users security devices =E2=80=93 the firewalls (something which = the discussed 3 drafts now finally can remedy (without the use of = Origin)) * However, the Application Provided TURN server may also be for (from = the RETURN draft: 3 Goals, 3.2 independent path control):=20 o improving quality of service by tunneling packets through a = network that is faster than the public internet, + monitoring the usage of UDP services, + troubleshooting and debugging problematic services, + logging connection metadata for legal or auditing reasons, + recording the entire contents of all connections, or - providing partial IP address anonymization (as described in = [I-D.ietf-rtcweb-security] Section 4.2.4). (+ and =E2=80=93 indicates the conflicting impact the use Origin will = bring for the listed purposes) =20 The RETURN draft honors the application=E2=80=99s efforts to enforce = media through such Application Provided TURN server (without judging the = purpose) (by use of the Recursively Encapsulation mechanism). =20 My advice now is just to not introduce the Origin discussion in these = drafts where we finally have to resolve the firewall traversal problem = with real-time traffic. We need these RFCs in place as soon as ever = possible. I see a risk in that draft-jennings-behave-rtcweb-firewall-00 = starts discussing Origin/SNI in an effort to make a pretty secure WebRTC = aware firewall somewhat more secure, and think the draft can advice = firewall vendors how to build firewalls that are fully secure and allows = real-time traffic and should also be able to provide a quality pipe for = the real-time traffic. Origin/SNI is not required for that. The Border = TURN server and this RETURN-draft will make that possible. =20 -- > Don=E2=80=99t forget the inline below -- > =20 Fr=C3=A5n: Benjamin Schwartz [mailto:bemasc@webrtc.org]=20 Skickat: den 14 juli 2015 03:16 Till: Karl Stahl Kopia: rtcweb@ietf.org; tram@ietf.org =C3=84mne: Re: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, = Configuration and TURN discovery: =20 On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl = wrote: We need this draft implemented in WebRTC browsers as soon as possible, = so we can get good WebRTC in difficult places (for firewall traversal and for quality). Is there any implementation e.g. in Chrome that can be tried? Now having stated that I am positive to this draft, I have some concerns/questions/suggestions: 1) We need more levels than sealed/leaky It is not acceptable that WebRTC traffic between parties on a typical = LAN is forced through a TURN server, just because of a sealed configuration required for good WebRTC traffic over the WAN. This consequence is = pointed out under "5.11. Reusing the same TURN server", but IS a problem even = if it "work as expected". Such TURN resource consumption, waste of bandwidth and possible = performance degradation do not happen today, and can easily be avoided. I realize this consequence of "sealed" is required to meet some of the requirements under "3.2. Independent Path Control", but we simply need = an "exo-sealed" level, in addition to the proposed strictly sealed and = leaky, allowing local endpoints to connect media directly, while external = traffic is forced to use the TURN server (rather than STUN through the default gateway). =20 [BS] How do you propose to tell what is "local"? I don't know how to = define that procedurally. =20 [BS] I think my main concern here is that it requires us to "lie" to the = remote party, by sending candidates that we may then refuse to use even = if they work. This seems very strange. =20 [Karl] You are right. I assumed the preferred exo-sealed behavior could = be achieved as easily as we do it =E2=80=9Chardware wise=E2=80=9D today = on the inside of our open test-site https://webrtc.ingate.com where we = have a border placed TURN server paralleling our firewall/default = gateway. Our firewall looks for the magic STUN cookie and discards all = STUN packets from the LAN side. TURN is then automatically enforced and = today=E2=80=99s leaky WebRTC browsers automatically get the preferred = exo-sealed behavior. =20 (Just not using STUN in the browser, would have the same effect but not = fully, if there are more subnets on the LAN side. Crossing those subnets = would then take media through the dual trip via the TURN server that I = want to avoid.) =20 So, let=E2=80=99s enforce the preferred exo-sealed configuration by = configuration of the firewall/default gateway (Security from this = perspective is then also in the right hands - the network = admin=E2=80=99s):=20 - Today=E2=80=99s RETURN-draft=E2=80=99s leaky default configuration is = OK (since the firewalls discarding STUN automatically enforce the = preferred exo-sealed behavior) - Recommend in the RETURN-draft (and in = draft-jennings-behave-rtcweb-firewall-00) that the network admin = discards STUN packets from the LAN side through the default gateway = (consent STUNs will go OK through the TURN server), by looking for the = magic STUN cookie, by closing port 3478 or by closing all UDP (the = restrictive enterprise firewall can simply be left as it is) to achieve = exo-sealed leakiness.=20 - The network admin offers a Border TURN server for its network users = (LAN side only) =E2=80=93 no need for authentication (free to use from = LAN side being a Border TURN server configuration)=20 - The Border TURN server is offered by the network you are using = =E2=80=93 Just use it! (should the network provider have evil = intentions, he needs no TURN server, he can simply close or destroy = WebRTC in the firewall if he which, which Cullen just exemplified in = draft-jennings-behave-rtcweb-firewall-00) =20 As you may have noticed, I stress that NO credentials should be needed = for using an auto discovered border TURN server. That is also the goal = of TRAM=E2=80=99s discovery draft, but I have asked TRAM to clarify = that achievement. If we don=E2=80=99t fix that, we have failed to make = WebRTC usable on mobile devices =E2=80=93 or can anyone explain where we = would get those credentials from when we run around and have Web access = here and there and the goal of WebRTC was to use real-time = communication, securely and with high quality, everywhere we can surf, = wasn=E2=80=99t it?=20 =20 If anyone cries that we NEED AUTHENTICATION, they should remember the IP = authentication (simply being on a certain network) is the most commonly = used =E2=80=9Cauthentication method=E2=80=9D today and protecting huge = values (almost the whole telco industry) and also achieves privacy = (through the use of firewalls). No individual user credentials which are = impossible to handle must be required. =20 I will in next email propose this new variant of the Anycast method to = TRAM. It should work, shouldn=E2=80=99t it? And does it provide the claimed advantages/features? =E2=80=93 please = check. =20 Implicit discovery by interception of TURN allocate requests at a = default gateway =20 An enterprise firewall or a network server provider=E2=80=99s router at = a default gateway can intercept a TURN allocate request and respond with = a 300 (Try Alternate) just as described in the Anycast method above. The = following procedures and advantages are inherited from the anycast = method. =20 This variant adds the following features: - no separate deployment of discovery mechanism is required - no ANA allocated anycast address is required (works with any public ip = address)=20 - the default gateway router/firewall in charge of the local network = responds with the ip address of: (i) a Border TURN server (paralleling the default gateway), or=20 (ii) a TURN server behind that firewall/default gateway and opens a = path to that TURN server =20 - if the intercepted allocate request was intended for an application = provided TURN server, the TURN client (e.g. WebRTC browser) on behalf of = the user, can select to: (iii) only use the auto discovered TURN server (iv) honor an allocation request by really sending the real-time = traffic to the Application Provided TURN server, using the Recursively = Encapsulated method, unless (v) the TURN server connected in (ii) already is the Application = Provided TURN server =20 Security wise, the right party is in charge in all cases. A TURN server pinpointed by a firewall/router at the default gateway = should always be trusted (no explicit authentication with credentials is = needed) and used. (We trust the default gateway with all our traffic = anyway, and any evil intent to disturb real-time traffic can in such = case be implemented in a default gateway by easier means.) =20 =20 Such "exo-sealed" configuration should be the default configuration if a network provided TURN server is made available for good (non-evil) = purposes. 2) Mobile devices need to work on various networks, without individual configuration I am not clear about the thoughts behind the "configuration" of sealed = level and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials = and force a certain sealed level upon the WebRTC-browser when used at that = LAN, or if the user has the possibility to configure manually, I am OK with = that this can and should OVERRIDE any default configuration or other configuration (on that particular network). However, for mobile devices - Don't we all happily connect our browsers = via WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should = be used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network. A network provided TURN-server can easily be made available ONLY to the network users that it is serving, so there is no need for authentication = and credentials to protect against illegal usage of a valuable resource, = like it is with the application provided turn server. Network provided TURN = servers are simply deployed for the network users to be use without other authentication than being granted an IP address and a default gateway to = use on that particular network in itself. The same goes for trusting the TURN server with our real-time traffic - = If we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our network: Data through the default gateway, RTC through the TURN path is why the = TURN server is provided! But do we know that it is not someone with the evil purpose of stealing = our (encrypted!) real time traffic that is offering the TURN server (instead = of the network provider), which leads us to my point 3). (If we really = think there is a risk of and danger with such attacks...) 3) Is it now good enough to simply use the auto discovered TURN server? = Hope so! There has been some recent improvements to draft-ietf-tram-turn-server-discovery-03 and hopefully that is = sufficient for assuming that the auto-discovered TURN server is offered by our = network provider (a service provider or the enterprise itself) that we trust = anyway, and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be leaky.) =20 The security considerations in that document suggest that not all = discovery mechanisms have equal additional exposure to local network = interference. I would appreciate clearer guidance on that front. It = seems to me that DHCP is the only listed mechanism that creates minimal = additional exposure to network interference. =20 --- I am addressing TRAM about this and believe that the variant of the = Anycast method I suggest to be added, will fully resolve all security = concerns. I am also suggesting that it is up to this RTCWEB draft to = select from TRAM=E2=80=99s methods and advices for the WebRTC = application and its use cases. =20 --- See my deployment concerns regarding DHCP put in front of TRAM. I = think that the Anycast method with a short TTL-limitation is good enough = from the privacy aspect, when used to find Border TURN server. =20 --- Even though the new variant I propose is more secure and even easier = to deploy, I suggest that this RETURN draft mandates the use of the both = the Anycast method and its new variant. The reason is that already = today, all routers/firewalls at a default gateways can add the anycast = route required for discovery, while intercepting the TURN allocate = request and responding with the Try Alternate server probably requires a = software upgrade of installed firewalls and routers with default = gateways (a firewall in front of the default gateway can also do the = interception and response).=20 =20 Some concerns regarding the DISCOVERY draft and whether these things = should be specified in the RETURN document: - Is the above the case with all discovery methods proposed? Or shall = the RETURN document make one method mandatory to implement? - Can that method then be the Anycast method (which by far seems to be = the most convenient to deploy and to implement and should work for all = network types and in all devices operating systems). I think what is said under "9.3. Anycast" under "9. Security Considerations" is sufficient for trusting such discovered TURN server. What should then go into the = RETURN draft - or should the DISCOVERY draft be more specific? I don't fully understand the DISCOVERY draft's: "... three discovery mechanisms. The reason for providing multiple mechanisms is to maximize = the opportunity for discovery," - Can we really put the burden upon all WebRTC devices to implement all methods and I doubt network providers will deploy more than one method. = That seems risking rather than maximizing discovery... It is high time to get this done - can we? /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r = internet-drafts@ietf.org Skickat: den 14 maj 2015 00:29 Till: i-d-announce@ietf.org Kopia: rtcweb@ietf.org =C3=84mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. Title : Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Authors : Benjamin M. Schwartz Justin Uberti Filename : draft-ietf-rtcweb-return-00.txt Pages : 18 Date : 2015-05-13 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------=_NextPart_000_0216_01D0C260.BF6F3650 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Be= njamin =E2=80=93 your concern is valid =E2=80=93 I thought exo-sealed = was easy to do in the browser.

 

Be= low I list a firewall configuration assisted method to address the TURN = server and bandwidth resource consumption problem for local WebRTC calls = when using the sealed configuration. I believe my suggestion also will = meet all security/trust/privacy perspectives and give secure = auto-configuration, so mobile devices can to be used with high-quality = secure WebRTC communication =E2=80=9Ceverywhere you can surf=E2=80=9D = =C2=A0through proper use of Border TURN servers - which must be the = (almost already achieved) purpose of this RETURN = draft.

 

Af= ter some consideration, to achieve the preferred exo-sealed = configuration, the RETURN drafts already prescribes the best default = configuration: =E2=80=9Cleaky=E2=80=9D ! :-)

Ex= planations inline below -->

 

Be= low are also some suggestions for inclusion in the = drafts:

draft-ietf-tr= am-turn-server-discovery-03

draft-jenning= s-behave-rtcweb-firewall-00

 

/K= arl

 

PS= : Regarding the TURN Origin debate, I don=E2=80=99t have a clear view, = but am I not right in the understanding that:

* = The purpose of the TURN Origin draft =C2=A0was to reduce the pain of = WebRTC service providers having to deploy network hardware (the = Application Provided TURN server) to get their services used, by = allowing the TURN server to serve many applications (through a third = party).

=C2= =A0- The introduction of Border TURN servers releases WebRTC service = providers of that pain (when commonly deployed) (and also put security = back in the right place) (Until deployed commonly, yes these SPs = unfortunately have this pain to =E2=80=9Cfool their services=E2=80=9D = through users security devices =E2=80=93 the firewalls (something which = the discussed 3 drafts now finally can remedy (without the use of = Origin))

* = However, the Application Provided TURN server may also be for (from the = RETURN draft: 3 Goals, 3.2 independent path control): =

=C2= =A0=C2=A0=C2=A0o=C2=A0 improving quality of service by tunneling packets = through a network that is faster than the public = internet,

=C2= =A0=C2=A0 +=C2=A0 monitoring the usage of UDP = services,

=C2= =A0=C2=A0 +=C2=A0 troubleshooting and debugging problematic = services,

=C2= =A0=C2=A0 +=C2=A0 logging connection metadata for legal or auditing = reasons,

=C2= =A0=C2=A0 +=C2=A0 recording the entire contents of all connections, = or

=C2= =A0=C2=A0 -=C2=A0 providing partial IP address anonymization (as = described in [I-D.ietf-rtcweb-security] Section = 4.2.4).

(+= and =E2=80=93 indicates the conflicting impact the use Origin will = bring for the listed purposes)

 

Th= e RETURN draft honors the application=E2=80=99s efforts to enforce media = through such Application Provided TURN server (without judging the = purpose) (by use of the Recursively Encapsulation = mechanism).

 

My= advice now is just to not introduce the Origin discussion in these = drafts where we finally have to resolve the firewall traversal problem = with real-time traffic. We need these RFCs in place as soon as ever = possible. I see a risk in that draft-jenning= s-behave-rtcweb-firewall-00 starts discussing = Origin/SNI in an effort to make a pretty secure WebRTC aware firewall = somewhat more secure, and think the draft can advice firewall vendors = how to build firewalls that are fully secure and allows real-time = traffic and should also be able to provide a quality pipe for the = real-time traffic. Origin/SNI is not required for that. The Border TURN = server and this RETURN-draft will make that = possible.

 

--= > Don=E2=80=99t forget the inline below -- = >

 

Fr=C3=A5n: Benjamin = Schwartz [mailto:bemasc@webrtc.org]
Skickat: den 14 juli 2015 = 03:16
Till: Karl Stahl
Kopia: rtcweb@ietf.org; = tram@ietf.org
=C3=84mne: Re: [rtcweb] = draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN = discovery:

 

On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

We need this draft implemented in WebRTC browsers as = soon as possible, so we
can get good WebRTC in difficult places (for = firewall traversal and for
quality). Is there any implementation e.g. = in Chrome that can be tried?

Now having stated that I am positive = to this draft, I have some
concerns/questions/suggestions:

1) = We need more levels than sealed/leaky

It is not acceptable that = WebRTC traffic between parties on a typical LAN is
forced through a = TURN server, just because of a sealed configuration
required for good = WebRTC traffic over the WAN. This consequence is pointed
out under = "5.11.  Reusing the same TURN server", but IS a problem = even if it
"work as expected".

Such TURN resource = consumption, waste of bandwidth and possible performance
degradation = do not happen today, and can easily be avoided.

I realize this = consequence of "sealed" is required to meet some of = the
requirements under "3.2.  Independent Path = Control", but we simply need an
"exo-sealed" level, in = addition to the proposed strictly sealed and leaky,
allowing local = endpoints to connect media directly, while external traffic
is forced = to use the TURN server (rather than STUN through the = default
gateway).

 

[BS] = How do you propose to tell what is = "local"?  I don't know how to define that = procedurally.

 

[BS] = I think my main concern here is that it = requires us to "lie" to the remote party, by sending = candidates that we may then refuse to use even if they work.  = This seems very strange.

 

[K= arl] You are right. I assumed the preferred exo-sealed behavior could be = achieved as easily as we do it =E2=80=9Chardware wise=E2=80=9D today on = the inside of our open test-site https://webrtc.ingate.com where = we have a border placed TURN server paralleling our firewall/default = gateway. Our firewall looks for the magic STUN cookie and discards all = STUN packets from the LAN side. TURN is then automatically enforced and = today=E2=80=99s leaky WebRTC browsers automatically get the preferred = exo-sealed behavior.

 

(J= ust not using STUN in the browser, would have the same effect but not = fully, if there are more subnets on the LAN side. Crossing those subnets = would then take media through the dual trip via the TURN server that I = want to avoid.)

 

So= , let=E2=80=99s enforce the preferred exo-sealed configuration by = configuration of the firewall/default gateway (Security from this = perspective is then also in the right hands - the network = admin=E2=80=99s):

- = Today=E2=80=99s RETURN-draft=E2=80=99s leaky default configuration is OK = (since the firewalls discarding STUN automatically enforce the preferred = exo-sealed behavior)

- = Recommend in the RETURN-draft (and in draft-jenning= s-behave-rtcweb-firewall-00) =C2=A0that the = network admin discards STUN packets from the LAN side through the = default gateway (consent STUNs will go OK through the TURN server), by = looking for the magic STUN cookie, by closing port 3478 or by closing = all UDP (the restrictive enterprise firewall can simply be left as it = is) to achieve exo-sealed leakiness.

- = The network admin offers a Border TURN server for its network users (LAN = side only) =E2=80=93 no need for authentication (free to use from LAN = side being a Border TURN server configuration)

- = The Border TURN server is offered by the network you are using =E2=80=93 = Just use it! (should the network provider have evil intentions, he needs = no TURN server, he can simply close or destroy WebRTC in the firewall if = he which,=C2=A0 which Cullen just exemplified in draft-jenning= s-behave-rtcweb-firewall-00)

 

As= you may have noticed, I stress that NO credentials should be needed for = using an auto discovered border TURN server. That is also the goal of = TRAM=E2=80=99s discovery draft, but I have asked TRAM =C2=A0to clarify = that achievement. If we don=E2=80=99t fix that, we have failed to make = WebRTC usable on mobile devices =E2=80=93 or can anyone explain where we = would get those credentials from when we run around and have Web access = here and there and the goal of WebRTC was to use real-time = communication, securely and with high quality, everywhere we can surf, = wasn=E2=80=99t it?

 

If= anyone cries that we NEED AUTHENTICATION, they should remember the IP = authentication (simply being on a certain network) is the most commonly = used =E2=80=9Cauthentication method=E2=80=9D today and protecting huge = values (almost the whole telco industry) and also achieves privacy = (through the use of firewalls). No individual user credentials which are = impossible to handle must be required.

 

I = will in next email propose this new variant of the Anycast method = =C2=A0to TRAM. It should work, shouldn=E2=80=99t = it?

An= d does it provide the claimed advantages/features? =E2=80=93 please = check.

 

Implicit discovery by interception = of TURN allocate requests at a default = gateway

 

An enterprise firewall = or a network server provider=E2=80=99s router at a default gateway can = intercept a TURN allocate request and respond with a 300 (Try Alternate) = just as described in the Anycast method above. The following procedures = and advantages are inherited from the anycast = method.

 

This variant adds the following features:

- no separate deployment of discovery mechanism is = required

- no ANA allocated anycast address = is required (works with any public ip address)

- the default gateway router/firewall in charge of the local = network responds with the ip address of:

(i) =C2=A0=C2=A0a Border TURN server (paralleling the default = gateway), or

(ii) =C2=A0a TURN = server behind that firewall/default gateway and opens a path to that = TURN server =C2=A0

- if the intercepted = allocate request was intended for an application provided TURN server, = the TURN client (e.g. WebRTC browser) on behalf of the user, can select = to:

(iii) only use the auto discovered = TURN server

(iv) =C2=A0honor an = allocation request by really sending the real-time traffic to the = Application Provided TURN server, using the Recursively Encapsulated = method, unless

(v) =C2=A0=C2=A0the = TURN=C2=A0 server connected in (ii) already is the Application Provided = TURN server

 

Security wise, the = right party is in charge in all cases.

A TURN server pinpointed by a firewall/router at the default = gateway should always be trusted (no explicit authentication with = credentials is needed) and used. (We trust the default gateway with all = our traffic anyway, and any evil intent to disturb real-time traffic can = in such case be implemented in a default gateway by easier = means.)

 

 

Such "exo-sealed" configuration should be the = default configuration if a
network provided TURN server is made = available for good (non-evil) purposes.


2) Mobile = devices need to work on various networks, without = individual
configuration

I am not clear about the thoughts = behind the "configuration" of sealed level
and requirements = for authentication of the turn server, but if there are
methods where = an enterprise network (LAN) admin can provide credentials and
force a = certain sealed level upon the WebRTC-browser when used at that = LAN,
or if the user has the possibility to configure manually, I am = OK with that
this can and should OVERRIDE any default configuration = or other
configuration (on that particular network).

However, = for mobile devices - Don't we all happily connect our browsers = via
WiFi here and there? - there must be a way for a network provider = with a
good intent to offer an exo-sealed TURN server that = automatically should be
used, e.g. to achieve the purpose of offering = better RTC quality than is
available through the default gateway WAN = path on that network.

A network provided TURN-server can easily = be made available ONLY to the
network users that it is serving, so = there is no need for authentication and
credentials to protect = against illegal usage of a valuable resource, like it
is with the = application provided turn server. Network provided TURN servers
are = simply deployed for the network users to be use without = other
authentication than being granted an IP address and a default = gateway to use
on that particular network in itself.

The same = goes for trusting the TURN server with our real-time traffic - If
we = would trust the same network provider with the same real-time = traffic
through the default gateway - we should also use the offered = TURN server
without other "authentication" than that it is = available on our network:
Data through the default gateway, RTC = through the TURN path is why the TURN
server is provided!

But = do we know that it is not someone with the evil purpose of stealing = our
(encrypted!) real time traffic that is offering the TURN server = (instead of
the network provider), which leads us to my point 3). (If = we really think
there is a risk of and danger with such = attacks...)


3) Is it now good enough to simply use the auto = discovered TURN server? Hope
so!

There has been some recent = improvements to
draft-ietf-tram-turn-server-discovery-03 and = hopefully that is sufficient
for assuming that the auto-discovered = TURN server is offered by our network
provider (a service provider or = the enterprise itself) that we trust anyway,
and the TURN server then = simply shall be used and considered exo-sealed.
(The current RETURN = draft says a non configured TURN server should = be
leaky.)

 

The security considerations in that document suggest = that not all discovery mechanisms have equal additional exposure to = local network interference.  I would appreciate clearer guidance on = that front.  It seems to me that DHCP is the only listed mechanism = that creates minimal additional exposure to network = interference.

 

--= - I am addressing TRAM about this and believe that the variant of the = Anycast method I suggest to be added, will fully resolve all security = concerns. I am also suggesting that it is up to this RTCWEB draft to = select from TRAM=E2=80=99s methods and advices for the WebRTC = application and its use cases.

 

--= - See my deployment concerns regarding DHCP put in front of TRAM. I = think that the Anycast method with a short TTL-limitation is good enough = from the privacy aspect, when used to find Border TURN = server.

 

--= - Even though the new variant I propose is more secure and even easier = to deploy, I suggest that this RETURN draft mandates the use of the both = the Anycast method and its new variant. The reason is that already = today, all routers/firewalls at a default gateways can add the anycast = route required for discovery, while intercepting the TURN=C2=A0 allocate = request and responding with the Try Alternate server probably requires a = software upgrade of installed =C2=A0firewalls and routers with default = gateways (a firewall in front of the default gateway can also do the = interception and response).

 

Some concerns = regarding the DISCOVERY draft and whether these things should
be = specified in the RETURN document:

- Is the above the case with = all discovery methods proposed? Or shall the
RETURN document = make one method mandatory to implement?

- Can that method then be = the Anycast method (which by far seems to be the
most convenient to = deploy and to implement and should work for all network
types and in = all devices operating systems). I think what is said = under
"9.3.  Anycast" under "9.  Security = Considerations" is sufficient for
trusting such discovered TURN = server. What should then go into the RETURN
draft - or should the = DISCOVERY draft be more specific?

I don't fully understand the = DISCOVERY draft's: "... three discovery
mechanisms. The reason = for providing multiple mechanisms is to maximize the
opportunity for = discovery,"

- Can we really put the burden upon all WebRTC = devices to implement all
methods and I doubt network providers will = deploy more than one method. That
seems risking rather than = maximizing discovery...


It is high time to get this done - = can we?

/Karl



-----Ursprungligt = meddelande-----
Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r internet-drafts@ietf.org
Skickat: den 14 maj = 2015 00:29
Till: i-d-announce@ietf.org
Kopia: rtcweb@ietf.org
=C3=84mne: [rtcweb] I-D Action: = draft-ietf-rtcweb-return-00.txt


A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
 This = draft is a work item of the Real-Time Communication in = WEB-browsers
Working Group of the IETF.

      =   Title           : Recursively = Encapsulated TURN (RETURN) for
Connectivity and Privacy in = WebRTC
        Authors        =  : Benjamin M. Schwartz
          =                 Justin = Uberti
        Filename      =   : draft-ietf-rtcweb-return-00.txt
        = Pages           : 18
    =     Date            : = 2015-05-13

Abstract:
   In the context of WebRTC, = the concept of a local TURN proxy has been
   suggested, = but not reviewed in detail.  WebRTC applications are
  =  already using TURN to enhance connectivity and privacy.  = This
   document explains how local TURN proxies and WebRTC = applications can
   work together.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-retu= rn/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-return-00=


Please note that it may take a couple of minutes from = the time of submission
until the htmlized version and diff are = available at tools.ietf.org.

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

________= _______________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 

------=_NextPart_000_0216_01D0C260.BF6F3650-- From nobody Sun Jul 19 11:35:19 2015 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 B67B01A8909 for ; Sun, 19 Jul 2015 11:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 Z_773qiCCkw8 for ; Sun, 19 Jul 2015 11:35:03 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B7A1A8906 for ; Sun, 19 Jul 2015 11:35:02 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201507192035036003; Sun, 19 Jul 2015 20:35:03 +0200 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Simon Perreault'" , "'Benjamin Schwartz'" , "'Cullen Jennings \(fluffy\)'" , "'Adam Roach'" Date: Sun, 19 Jul 2015 20:34:59 +0200 Message-ID: <022601d0c251$9e1944a0$da4bcde0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0227_01D0C262.61A214A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDCUZ29mVhXf6BkRV6lqyfks2yLHQ== Content-Language: sv Archived-At: Cc: tram@ietf.org Subject: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03 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, 19 Jul 2015 18:35:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0227_01D0C262.61A214A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don=92t think draft-ietf-tram-turn-server-discovery-03 draft is not = clear enough yet. Hopefully the my suggestions below are non-controversial, only = improvements, so we can make this draft an RFC as soon as possible. =20 The following should be read in the context of the email below to the = RTCWEB WG. =20 1) The result of the valid discussion/concerns=20 Ending at: https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1FmpOg=20 about how to achieve auto-configuration (e.g. necessary for good and = secure use of WebRTC on mobile devices) and the consequent necessity to be able = to use the auto discovered TURN server without credentials, and further = that a locally placed turn can achieve this by being available only from a = trusted network, should be clarified and for which discovery methods it is achieved. =20 =20 2) Tiru, you and I have had some discussion a year ago or so about (From = 1. Introduction):=20 =93The reason for providing multiple mechanisms is to maximize the = opportunity for discovery, based on the network in which the TURN client finds = itself.=94=20 =20 I questioned whether that goal really can be achieved unless we mandate (MUST implement) common methods, and whether it is up to this draft or = some RTCWEB draft to be responsible for that. With the appearance of=20 draft-ietf-rtcweb-return-00 draft-jennings-behave-rtcweb-firewall-00 we now have a chance to clarify this. =20 I fully agree with the goal and necessity of this draft, but suggest = some rephrasing of the Introduction: =93To allow TURN applications operate real-time traffic seamlessly = across different types of networks and encourage by the use of TURN without the need for manual configuration, it is important that there exists an auto discovery mechanism for TURN services. Real-time applications and specifically Web Real-Time Communication = (WebRTC)[I-D.ietf-rtcweb-overview] usages and related extensions, which are mostly based on web = applications, need this immediately. =20 And that the =93multiple mechanism=94 sentence is replaced by: =93This document recommends multiple discovery mechanism, and advices = about security such as trust and privacy as well as deployment efforts. It is = up to the specific real-time application recommendation and its use case to select from these recommendations and advices.=94=20 =20 draft-ietf-rtcweb-return-00 can then specify how the browser shall = implement auto discovery for WebRTC and draft-jennings-behave-rtcweb-firewall-00 can then advice firewall vendors how to achieve the goals of this draft=20 =20 3) The concept of =93sealed=94, =93leaky=94 and =93exo-leaky=94 (see = discussion below), the Recursively Encapsulated method and Border TURN server should be mentioned and conform with draft-ietf-rtcweb-return-00. =20 4) Explain that the leakiness for a discovered local TURN server can be = auto configured. E.g.: =93The default gateway router/firewall can block STUN packets by looking = for the magic STUN cookie, by closing port 3478 or by closing all UDP = traffic, to enforce an exo-sealed configuration for a TURN client having a leaky default configuration, thus improving security, while avoiding the = overhead of sending the real-time traffic through the TURN server (twice) with = sealed a TURN client configuration (as explained in = draft-ietf-rtcweb-return-00). =20 5) After =936. Discovery using Anycast=94 section, add a variant: =20 Implicit discovery by interception of TURN allocate requests at a = default gateway =20 An enterprise firewall or a network server provider=92s router at a = default gateway can intercept a TURN allocate request and respond with a 300 = (Try Alternate) just as described in the Anycast method above. The following procedures and advantages are inherited from the anycast method. =20 This variant adds the following features: - no separate deployment of discovery mechanism is required - no ANA allocated anycast address is required (works with any public ip address)=20 - the default gateway router/firewall in charge of the local network responds with the ip address of: (i) a Border TURN server (paralleling the default gateway), or=20 (ii) a TURN server behind that firewall/default gateway and opens a = path to that TURN server =20 - if the intercepted allocate request was intended for an application provided TURN server, the TURN client (e.g. WebRTC browser) on behalf of = the user, can select to: (iii) only use the auto discovered TURN server (iv) honor an allocation request by really sending the real-time = traffic to the Application Provided TURN server, using the Recursively Encapsulated method, unless (v) the TURN server connected in (ii) already is the Application = Provided TURN server =20 Security wise, the right party is in charge in all cases. A TURN server pinpointed by a firewall/router at the default gateway = should always be trusted (no explicit authentication with credentials is = needed) and used. (We trust the default gateway with all our traffic anyway, and = any evil intent to disturb real-time traffic can in such case be implemented = in a default gateway by easier means.) =20 - the TURN server pinpointed by a default gateway shall always be = trusted and used and the security methods under 9.3 will not have to be applied. =20 [Some of these features should be repeated under the Deployment and = Security sections] =20 6) Under =937. Deployment Considerations=94, the ease of the Anycast = method and suggested variant could be pointed out. Those methods can be used over = any network and by TURN clients under common operating systems. =20 It should be adviced to configure discovered TURN servers to be allowed = to be used without credentials for the users that they are intended to = serve, to achieve the goal of this draft (simply by make the TURN server = available to allocate from, only on the network it is supposed to serve, thus no credentials are needed to protect the TURN server resource as with the application provided TURN servers). =20 The DHCP method may also be easy to deploy where used (e.g. Enterprise, = Home and WiFi). However, with IPV6, RA (Router Advertisement) is often used instead of DHCP to hand out ip addresses. The important mobile world (3G/4G/LTE) has its own methods, and there are still PPoE and PPoA in = use, where DHCP cannot be used. If a network service provides announces a = TURN server using DHCP, the following firewall needs to pick that up and = advice that to the users on the LAN. DHCP may not be available on some = operating systems where the TURN client, specifically the WebRTC device, should be able to be implemented on.=20 =20 7)I don=92t understand the sentences under =939. Security = Considerations=94 =93In general, it is recommended that a TURN client authenticate with = the TURN server to identify a rouge server. [RFC7350] can be potentially used by = a client to validate a previously unknown server.=94 It must be explained and detailed, how and what is authenticated or validated, for what purpose and how this may help to achieve the goals = of this recommendation, or these sentences should simply be deleted. =20 =20 I hope this improves this necessary and good draft and that it quickly = can be adopted. =20 /Karl =20 =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Karl Stahl Skickat: den 19 juli 2015 20:23 Till: 'Benjamin Schwartz'; 'Cullen Jennings (fluffy)' Kopia: rtcweb@ietf.org; tram@ietf.org =C4mne: Re: [tram] [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery: =20 Benjamin =96 your concern is valid =96 I thought exo-sealed was easy to = do in the browser. =20 Below I list a firewall configuration assisted method to address the = TURN server and bandwidth resource consumption problem for local WebRTC calls when using the sealed configuration. I believe my suggestion also will = meet all security/trust/privacy perspectives and give secure = auto-configuration, so mobile devices can to be used with high-quality secure WebRTC communication =93everywhere you can surf=94 through proper use of = Border TURN servers - which must be the (almost already achieved) purpose of this = RETURN draft. =20 After some consideration, to achieve the preferred exo-sealed = configuration, the RETURN drafts already prescribes the best default configuration: = =93leaky=94 ! :-)=20 Explanations inline below --> =20 Below are also some suggestions for inclusion in the drafts: draft-ietf-tram-turn-server-discovery-03 draft-jennings-behave-rtcweb-firewall-00 =20 /Karl =20 PS: Regarding the TURN Origin debate, I don=92t have a clear view, but = am I not right in the understanding that: * The purpose of the TURN Origin draft was to reduce the pain of WebRTC service providers having to deploy network hardware (the Application Provided TURN server) to get their services used, by allowing the TURN server to serve many applications (through a third party).=20 - The introduction of Border TURN servers releases WebRTC service = providers of that pain (when commonly deployed) (and also put security back in the right place) (Until deployed commonly, yes these SPs unfortunately have = this pain to =93fool their services=94 through users security devices =96 the = firewalls (something which the discussed 3 drafts now finally can remedy (without = the use of Origin)) * However, the Application Provided TURN server may also be for (from = the RETURN draft: 3 Goals, 3.2 independent path control):=20 o improving quality of service by tunneling packets through a = network that is faster than the public internet, + monitoring the usage of UDP services, + troubleshooting and debugging problematic services, + logging connection metadata for legal or auditing reasons, + recording the entire contents of all connections, or - providing partial IP address anonymization (as described in [I-D.ietf-rtcweb-security] Section 4.2.4). (+ and =96 indicates the conflicting impact the use Origin will bring = for the listed purposes) =20 The RETURN draft honors the application=92s efforts to enforce media = through such Application Provided TURN server (without judging the purpose) (by = use of the Recursively Encapsulation mechanism). =20 My advice now is just to not introduce the Origin discussion in these = drafts where we finally have to resolve the firewall traversal problem with real-time traffic. We need these RFCs in place as soon as ever possible. = I see a risk in that draft-jennings-behave-rtcweb-firewall-00 starts discussing Origin/SNI in an effort to make a pretty secure WebRTC aware firewall somewhat more secure, and think the draft can advice firewall vendors how to build firewalls that are fully secure and allows = real-time traffic and should also be able to provide a quality pipe for the = real-time traffic. Origin/SNI is not required for that. The Border TURN server and this RETURN-draft will make that possible. =20 -- > Don=92t forget the inline below -- > =20 Fr=E5n: Benjamin Schwartz [mailto:bemasc@webrtc.org]=20 Skickat: den 14 juli 2015 03:16 Till: Karl Stahl Kopia: rtcweb@ietf.org; tram@ietf.org =C4mne: Re: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, = Configuration and TURN discovery: =20 On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl < karl.stahl@intertex.se> wrote: We need this draft implemented in WebRTC browsers as soon as possible, = so we can get good WebRTC in difficult places (for firewall traversal and for quality). Is there any implementation e.g. in Chrome that can be tried? Now having stated that I am positive to this draft, I have some concerns/questions/suggestions: 1) We need more levels than sealed/leaky It is not acceptable that WebRTC traffic between parties on a typical = LAN is forced through a TURN server, just because of a sealed configuration required for good WebRTC traffic over the WAN. This consequence is = pointed out under "5.11. Reusing the same TURN server", but IS a problem even = if it "work as expected". Such TURN resource consumption, waste of bandwidth and possible = performance degradation do not happen today, and can easily be avoided. I realize this consequence of "sealed" is required to meet some of the requirements under "3.2. Independent Path Control", but we simply need = an "exo-sealed" level, in addition to the proposed strictly sealed and = leaky, allowing local endpoints to connect media directly, while external = traffic is forced to use the TURN server (rather than STUN through the default gateway). =20 [BS] How do you propose to tell what is "local"? I don't know how to = define that procedurally. =20 [BS] I think my main concern here is that it requires us to "lie" to the remote party, by sending candidates that we may then refuse to use even = if they work. This seems very strange. =20 [Karl] You are right. I assumed the preferred exo-sealed behavior could = be achieved as easily as we do it =93hardware wise=94 today on the inside = of our open test-site https://webrtc.ingate.com where we have a border placed = TURN server paralleling our firewall/default gateway. Our firewall looks for = the magic STUN cookie and discards all STUN packets from the LAN side. TURN = is then automatically enforced and today=92s leaky WebRTC browsers = automatically get the preferred exo-sealed behavior. =20 (Just not using STUN in the browser, would have the same effect but not fully, if there are more subnets on the LAN side. Crossing those subnets would then take media through the dual trip via the TURN server that I = want to avoid.) =20 So, let=92s enforce the preferred exo-sealed configuration by = configuration of the firewall/default gateway (Security from this perspective is then = also in the right hands - the network admin=92s):=20 - Today=92s RETURN-draft=92s leaky default configuration is OK (since = the firewalls discarding STUN automatically enforce the preferred exo-sealed behavior) - Recommend in the RETURN-draft (and in draft-jennings-behave-rtcweb-firewall-00) that the network admin = discards STUN packets from the LAN side through the default gateway (consent = STUNs will go OK through the TURN server), by looking for the magic STUN = cookie, by closing port 3478 or by closing all UDP (the restrictive enterprise firewall can simply be left as it is) to achieve exo-sealed leakiness.=20 - The network admin offers a Border TURN server for its network users = (LAN side only) =96 no need for authentication (free to use from LAN side = being a Border TURN server configuration)=20 - The Border TURN server is offered by the network you are using =96 = Just use it! (should the network provider have evil intentions, he needs no TURN server, he can simply close or destroy WebRTC in the firewall if he = which, which Cullen just exemplified in = draft-jennings-behave-rtcweb-firewall-00) =20 As you may have noticed, I stress that NO credentials should be needed = for using an auto discovered border TURN server. That is also the goal of = TRAM=92s discovery draft, but I have asked TRAM to clarify that achievement. If = we don=92t fix that, we have failed to make WebRTC usable on mobile devices = =96 or can anyone explain where we would get those credentials from when we run around and have Web access here and there and the goal of WebRTC was to = use real-time communication, securely and with high quality, everywhere we = can surf, wasn=92t it?=20 =20 If anyone cries that we NEED AUTHENTICATION, they should remember the IP authentication (simply being on a certain network) is the most commonly = used =93authentication method=94 today and protecting huge values (almost the = whole telco industry) and also achieves privacy (through the use of = firewalls). No individual user credentials which are impossible to handle must be = required. =20 I will in next email propose this new variant of the Anycast method to TRAM. It should work, shouldn=92t it? And does it provide the claimed advantages/features? =96 please check. =20 Implicit discovery by interception of TURN allocate requests at a = default gateway =20 An enterprise firewall or a network server provider=92s router at a = default gateway can intercept a TURN allocate request and respond with a 300 = (Try Alternate) just as described in the Anycast method above. The following procedures and advantages are inherited from the anycast method. =20 This variant adds the following features: - no separate deployment of discovery mechanism is required - no ANA allocated anycast address is required (works with any public ip address)=20 - the default gateway router/firewall in charge of the local network responds with the ip address of: (i) a Border TURN server (paralleling the default gateway), or=20 (ii) a TURN server behind that firewall/default gateway and opens a = path to that TURN server =20 - if the intercepted allocate request was intended for an application provided TURN server, the TURN client (e.g. WebRTC browser) on behalf of = the user, can select to: (iii) only use the auto discovered TURN server (iv) honor an allocation request by really sending the real-time = traffic to the Application Provided TURN server, using the Recursively Encapsulated method, unless (v) the TURN server connected in (ii) already is the Application = Provided TURN server =20 Security wise, the right party is in charge in all cases. A TURN server pinpointed by a firewall/router at the default gateway = should always be trusted (no explicit authentication with credentials is = needed) and used. (We trust the default gateway with all our traffic anyway, and = any evil intent to disturb real-time traffic can in such case be implemented = in a default gateway by easier means.) =20 =20 Such "exo-sealed" configuration should be the default configuration if a network provided TURN server is made available for good (non-evil) = purposes. 2) Mobile devices need to work on various networks, without individual configuration I am not clear about the thoughts behind the "configuration" of sealed = level and requirements for authentication of the turn server, but if there are methods where an enterprise network (LAN) admin can provide credentials = and force a certain sealed level upon the WebRTC-browser when used at that = LAN, or if the user has the possibility to configure manually, I am OK with = that this can and should OVERRIDE any default configuration or other configuration (on that particular network). However, for mobile devices - Don't we all happily connect our browsers = via WiFi here and there? - there must be a way for a network provider with a good intent to offer an exo-sealed TURN server that automatically should = be used, e.g. to achieve the purpose of offering better RTC quality than is available through the default gateway WAN path on that network. A network provided TURN-server can easily be made available ONLY to the network users that it is serving, so there is no need for authentication = and credentials to protect against illegal usage of a valuable resource, = like it is with the application provided turn server. Network provided TURN = servers are simply deployed for the network users to be use without other authentication than being granted an IP address and a default gateway to = use on that particular network in itself. The same goes for trusting the TURN server with our real-time traffic - = If we would trust the same network provider with the same real-time traffic through the default gateway - we should also use the offered TURN server without other "authentication" than that it is available on our network: Data through the default gateway, RTC through the TURN path is why the = TURN server is provided! But do we know that it is not someone with the evil purpose of stealing = our (encrypted!) real time traffic that is offering the TURN server (instead = of the network provider), which leads us to my point 3). (If we really = think there is a risk of and danger with such attacks...) 3) Is it now good enough to simply use the auto discovered TURN server? = Hope so! There has been some recent improvements to draft-ietf-tram-turn-server-discovery-03 and hopefully that is = sufficient for assuming that the auto-discovered TURN server is offered by our = network provider (a service provider or the enterprise itself) that we trust = anyway, and the TURN server then simply shall be used and considered exo-sealed. (The current RETURN draft says a non configured TURN server should be leaky.) =20 The security considerations in that document suggest that not all = discovery mechanisms have equal additional exposure to local network interference. = I would appreciate clearer guidance on that front. It seems to me that = DHCP is the only listed mechanism that creates minimal additional exposure to network interference. =20 --- I am addressing TRAM about this and believe that the variant of the Anycast method I suggest to be added, will fully resolve all security concerns. I am also suggesting that it is up to this RTCWEB draft to = select from TRAM=92s methods and advices for the WebRTC application and its use cases. =20 --- See my deployment concerns regarding DHCP put in front of TRAM. I = think that the Anycast method with a short TTL-limitation is good enough from = the privacy aspect, when used to find Border TURN server. =20 --- Even though the new variant I propose is more secure and even easier = to deploy, I suggest that this RETURN draft mandates the use of the both = the Anycast method and its new variant. The reason is that already today, = all routers/firewalls at a default gateways can add the anycast route = required for discovery, while intercepting the TURN allocate request and = responding with the Try Alternate server probably requires a software upgrade of installed firewalls and routers with default gateways (a firewall in = front of the default gateway can also do the interception and response).=20 =20 Some concerns regarding the DISCOVERY draft and whether these things = should be specified in the RETURN document: - Is the above the case with all discovery methods proposed? Or shall = the RETURN document make one method mandatory to implement? - Can that method then be the Anycast method (which by far seems to be = the most convenient to deploy and to implement and should work for all = network types and in all devices operating systems). I think what is said under "9.3. Anycast" under "9. Security Considerations" is sufficient for trusting such discovered TURN server. What should then go into the = RETURN draft - or should the DISCOVERY draft be more specific? I don't fully understand the DISCOVERY draft's: "... three discovery mechanisms. The reason for providing multiple mechanisms is to maximize = the opportunity for discovery," - Can we really put the burden upon all WebRTC devices to implement all methods and I doubt network providers will deploy more than one method. = That seems risking rather than maximizing discovery... It is high time to get this done - can we? /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto: rtcweb-bounces@ietf.org] F=F6r internet-drafts@ietf.org Skickat: den 14 maj 2015 00:29 Till: i-d-announce@ietf.org Kopia: rtcweb@ietf.org =C4mne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. Title : Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Authors : Benjamin M. Schwartz Justin Uberti Filename : draft-ietf-rtcweb-return-00.txt Pages : 18 Date : 2015-05-13 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: = ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 =20 ------=_NextPart_000_0227_01D0C262.61A214A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don’t think = draft-ietf-tram-turn-server-discovery-03 draft is not clear enough = yet.

Hopefully the my suggestions below = are non-controversial, only improvements, so we can make this draft an = RFC as soon as possible.

 

The following should be = read in the context of the email below to the RTCWEB = WG.

 

1) The result of the valid discussion/concerns =

Ending at: https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1F= mpOg

about how to achieve = auto-configuration (e.g. necessary for good and secure use of WebRTC on = mobile devices) and the consequent necessity to be able to use the auto = discovered TURN server without credentials, and further that a locally = placed turn can achieve this by being available only from a trusted = network,

should be clarified and for which = discovery methods it is achieved. =A0

 

2) Tiru, you and I have = had some discussion a year ago or so about (From 1.=A0 Introduction): =

“The reason for providing = multiple mechanisms is to maximize the opportunity for discovery, based = on the network in which the TURN client finds itself.” =

 

I questioned whether that goal really can be achieved unless we = mandate (MUST implement) common methods, and whether it is up to this = draft or some RTCWEB draft to be responsible for that. With the = appearance of

draft-ietf-rt= cweb-return-00

draft-jenning= s-behave-rtcweb-firewall-00

we now have a chance to clarify this.

 

I fully agree with the = goal and necessity of this draft, but suggest some rephrasing of the = Introduction:

“To allow TURN = applications operate real-time traffic seamlessly across = different types of networks and encourage by the use of = TURN without the need for manual configuration, it is important that = there exists an auto discovery mechanism for TURN services. Real-time = applications and specifically Web Real-Time Communication = (WebRTC)[I-D.ietf-rtcweb-overview] usages and related extensions, which = are mostly based on web applications, need this = immediately.

 

And that the = “multiple mechanism” sentence is replaced = by:

“This document recommends = multiple discovery mechanism, and advices about security such as trust = and privacy as well as deployment efforts. It is up to the specific = real-time application recommendation and its use case to select from = these recommendations and advices.”

 

draft-ietf-rt= cweb-return-00 can then specify how the browser shall implement auto discovery = for WebRTC

and draft-jenning= s-behave-rtcweb-firewall-00 can then advice firewall vendors how = to achieve the goals of this draft

 

3) The concept of = “sealed”, “leaky” and “exo-leaky” = (see discussion below), the Recursively Encapsulated method and Border = TURN server should be mentioned and conform with = draft-ietf-rtcweb-return-00.

 

4) Explain that the = leakiness for a discovered local TURN server can be auto configured. = E.g.:

“The default gateway = router/firewall can block STUN packets by looking for the magic STUN = cookie, by closing port 3478 or by closing all UDP traffic, to enforce = an exo-sealed configuration for a TURN client having a leaky default = configuration, thus improving security, while avoiding the overhead of = sending the real-time traffic through the TURN server (twice) with = sealed a TURN client configuration (as explained in draft-ietf-rt= cweb-return-00).

 

5) After “6.=A0 Discovery using Anycast” section, add = a variant:

 

Implicit discovery by = interception of TURN allocate requests at a default = gateway

 

An enterprise firewall = or a network server provider’s router at a default gateway can = intercept a TURN allocate request and respond with a 300 (Try Alternate) = just as described in the Anycast method above. The following procedures = and advantages are inherited from the anycast = method.

 

This variant adds the following features:

- no separate deployment of discovery mechanism is = required

- no ANA allocated anycast address = is required (works with any public ip address)

- the default gateway router/firewall in charge of the local = network responds with the ip address of:

(i)   a Border TURN server (paralleling the default = gateway), or

(ii)  a TURN = server behind that firewall/default gateway and opens a path to that = TURN server  

- if the intercepted = allocate request was intended for an application provided TURN server, = the TURN client (e.g. WebRTC browser) on behalf of the user, can select = to:

(iii) only use the auto discovered = TURN server

(iv)  honor an = allocation request by really sending the real-time traffic to the = Application Provided TURN server, using the Recursively Encapsulated = method, unless

(v)   the = TURN  server connected in (ii) already is the Application Provided = TURN server

 

Security wise, the = right party is in charge in all cases.

A TURN server pinpointed by a firewall/router at the default = gateway should always be trusted (no explicit authentication with = credentials is needed) and used. (We trust the default gateway with all = our traffic anyway, and any evil intent to disturb real-time traffic can = in such case be implemented in a default gateway by easier = means.)

 

- the TURN server pinpointed by a default gateway shall always be = trusted and used and the security methods under 9.3 will not have to be = applied.

 

[Some of these features should be repeated under the Deployment = and Security sections]

 

6) Under “7. = Deployment Considerations”, the ease of the Anycast method and = suggested variant could be pointed out. Those methods can be used over = any network and by TURN clients under common operating = systems.

 

It should be adviced to configure discovered TURN servers to be = allowed to be used without credentials for the users that they are = intended to serve, to achieve the goal of this draft (simply by make the = TURN server available to allocate from, only on the network it is = supposed to serve, thus no credentials are needed to protect the TURN = server resource as with the application provided TURN = servers).

 

The DHCP method may = also be easy to deploy where used (e.g. Enterprise, Home and WiFi). = However, with IPV6, RA (Router Advertisement) is often used instead of = DHCP to hand out ip addresses. The important mobile world (3G/4G/LTE) = has its own methods, and there are still PPoE and PPoA in use, where = DHCP cannot be used. If a network service provides announces a TURN = server using DHCP, the following firewall needs to pick that up and = advice that to the users on the LAN. DHCP may not be available on some = operating systems where the TURN client, specifically the WebRTC device, = should be able to be implemented on.

 

7)I don’t = understand the sentences under “9.=A0 Security = Considerations”

“In general, it = is recommended that a TURN client authenticate with the TURN server to = identify a rouge server. [RFC7350] can be potentially used by a client = to validate a previously unknown server.”

It must be explained and detailed, how and what is authenticated = or validated, for what purpose and how this may help to achieve the = goals of this recommendation, or these sentences should simply be = deleted.

 

 

I hope this improves = this necessary and good draft and that it quickly can be = adopted.

 

/Karl

 

 

Fr=E5n: tram = [mailto:tram-bounces@ietf.org] F=F6r Karl = Stahl
Skickat: den 19 juli 2015 20:23
Till: = 'Benjamin Schwartz'; 'Cullen Jennings (fluffy)'
Kopia: = rtcweb@ietf.org; tram@ietf.org
=C4mne: Re: [tram] [rtcweb] = draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN = discovery:

 

Be= njamin – your concern is valid – I thought exo-sealed was = easy to do in the browser.

 

Be= low I list a firewall configuration assisted method to address the TURN = server and bandwidth resource consumption problem for local WebRTC calls = when using the sealed configuration. I believe my suggestion also will = meet all security/trust/privacy perspectives and give secure = auto-configuration, so mobile devices can to be used with high-quality = secure WebRTC communication “everywhere you can surf” =  through proper use of Border TURN servers - which must be the = (almost already achieved) purpose of this RETURN = draft.

 

Af= ter some consideration, to achieve the preferred exo-sealed = configuration, the RETURN drafts already prescribes the best default = configuration: “leaky” ! :-)

Ex= planations inline below -->

 

Be= low are also some suggestions for inclusion in the = drafts:

draft-ietf-tr= am-turn-server-discovery-03

draft-jenning= s-behave-rtcweb-firewall-00

 

/K= arl

 

PS= : Regarding the TURN Origin debate, I don’t have a clear view, but = am I not right in the understanding that:

* = The purpose of the TURN Origin draft  was to reduce the pain of = WebRTC service providers having to deploy network hardware (the = Application Provided TURN server) to get their services used, by = allowing the TURN server to serve many applications (through a third = party).

&n= bsp;- The introduction of Border TURN servers releases WebRTC service = providers of that pain (when commonly deployed) (and also put security = back in the right place) (Until deployed commonly, yes these SPs = unfortunately have this pain to “fool their services” = through users security devices – the firewalls (something which = the discussed 3 drafts now finally can remedy (without the use of = Origin))

* = However, the Application Provided TURN server may also be for (from the = RETURN draft: 3 Goals, 3.2 independent path control): =

&n= bsp;  o  improving quality of service by tunneling = packets through a network that is faster than the public = internet,

&n= bsp;  +  monitoring the usage of UDP = services,

&n= bsp;  +  troubleshooting and debugging problematic = services,

&n= bsp;  +  logging connection metadata for legal or auditing = reasons,

&n= bsp;  +  recording the entire contents of all connections, = or

&n= bsp;  -  providing partial IP address anonymization (as = described in [I-D.ietf-rtcweb-security] Section = 4.2.4).

(+= and – indicates the conflicting impact the use Origin will bring = for the listed purposes)

 

Th= e RETURN draft honors the application’s efforts to enforce media = through such Application Provided TURN server (without judging the = purpose) (by use of the Recursively Encapsulation = mechanism).

 

My= advice now is just to not introduce the Origin discussion in these = drafts where we finally have to resolve the firewall traversal problem = with real-time traffic. We need these RFCs in place as soon as ever = possible. I see a risk in that draft-jenning= s-behave-rtcweb-firewall-00 starts discussing = Origin/SNI in an effort to make a pretty secure WebRTC aware firewall = somewhat more secure, and think the draft can advice firewall vendors = how to build firewalls that are fully secure and allows real-time = traffic and should also be able to provide a quality pipe for the = real-time traffic. Origin/SNI is not required for that. The Border TURN = server and this RETURN-draft will make that = possible.

 

--= > Don’t forget the inline below -- = >

 

Fr=E5n: Benjamin = Schwartz [mailto:bemasc@webrtc.org] =
Skickat: den 14 juli 2015 03:16
Till: Karl = Stahl
Kopia: rtcweb@ietf.org; tram@ietf.org
=C4mne: Re: = [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN = discovery:

 

On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

We = need this draft implemented in WebRTC browsers as soon as possible, so = we
can get good WebRTC in difficult places (for firewall traversal = and for
quality). Is there any implementation e.g. in Chrome that can = be tried?

Now having stated that I am positive to this draft, I = have some
concerns/questions/suggestions:

1) We need more = levels than sealed/leaky

It is not acceptable that WebRTC traffic = between parties on a typical LAN is
forced through a TURN server, = just because of a sealed configuration
required for good WebRTC = traffic over the WAN. This consequence is pointed
out under = "5.11.  Reusing the same TURN server", but IS a problem = even if it
"work as expected".

Such TURN resource = consumption, waste of bandwidth and possible performance
degradation = do not happen today, and can easily be avoided.

I realize this = consequence of "sealed" is required to meet some of = the
requirements under "3.2.  Independent Path = Control", but we simply need an
"exo-sealed" level, in = addition to the proposed strictly sealed and leaky,
allowing local = endpoints to connect media directly, while external traffic
is forced = to use the TURN server (rather than STUN through the = default
gateway).

 

[BS] How do = you propose to tell what is "local"?  I don't know how to = define that procedurally.

 

[BS] = I think my main concern here is that it = requires us to "lie" to the remote party, by sending = candidates that we may then refuse to use even if they work.  This = seems very strange.

 

[K= arl] You are right. I assumed the preferred exo-sealed behavior could be = achieved as easily as we do it “hardware wise” today on the = inside of our open test-site https://webrtc.ingate.com where = we have a border placed TURN server paralleling our firewall/default = gateway. Our firewall looks for the magic STUN cookie and discards all = STUN packets from the LAN side. TURN is then automatically enforced and = today’s leaky WebRTC browsers automatically get the preferred = exo-sealed behavior.

 

(J= ust not using STUN in the browser, would have the same effect but not = fully, if there are more subnets on the LAN side. Crossing those subnets = would then take media through the dual trip via the TURN server that I = want to avoid.)

 

So= , let’s enforce the preferred exo-sealed configuration by = configuration of the firewall/default gateway (Security from this = perspective is then also in the right hands - the network = admin’s):

- = Today’s RETURN-draft’s leaky default configuration is OK = (since the firewalls discarding STUN automatically enforce the preferred = exo-sealed behavior)

- = Recommend in the RETURN-draft (and in draft-jenning= s-behave-rtcweb-firewall-00)  that the = network admin discards STUN packets from the LAN side through the = default gateway (consent STUNs will go OK through the TURN server), by = looking for the magic STUN cookie, by closing port 3478 or by closing = all UDP (the restrictive enterprise firewall can simply be left as it = is) to achieve exo-sealed leakiness.

- = The network admin offers a Border TURN server for its network users (LAN = side only) – no need for authentication (free to use from LAN side = being a Border TURN server configuration)

- = The Border TURN server is offered by the network you are using – = Just use it! (should the network provider have evil intentions, he needs = no TURN server, he can simply close or destroy WebRTC in the firewall if = he which,  which Cullen just exemplified in draft-jenning= s-behave-rtcweb-firewall-00)

 

As= you may have noticed, I stress that NO credentials should be needed for = using an auto discovered border TURN server. That is also the goal of = TRAM’s discovery draft, but I have asked TRAM  to clarify = that achievement. If we don’t fix that, we have failed to make = WebRTC usable on mobile devices – or can anyone explain where we = would get those credentials from when we run around and have Web access = here and there and the goal of WebRTC was to use real-time = communication, securely and with high quality, everywhere we can surf, = wasn’t it?

 

If= anyone cries that we NEED AUTHENTICATION, they should remember the IP = authentication (simply being on a certain network) is the most commonly = used “authentication method” today and protecting huge = values (almost the whole telco industry) and also achieves privacy = (through the use of firewalls). No individual user credentials which are = impossible to handle must be required.

 

I = will in next email propose this new variant of the Anycast method =  to TRAM. It should work, shouldn’t = it?

An= d does it provide the claimed advantages/features? – please = check.

 

Implicit discovery by interception = of TURN allocate requests at a default = gateway

 

An enterprise firewall = or a network server provider’s router at a default gateway can = intercept a TURN allocate request and respond with a 300 (Try Alternate) = just as described in the Anycast method above. The following procedures = and advantages are inherited from the anycast = method.

 

This variant adds the following features:

- no separate deployment of discovery mechanism is = required

- no ANA allocated anycast address = is required (works with any public ip address)

- the default gateway router/firewall in charge of the local = network responds with the ip address of:

(i)   a Border TURN server (paralleling the default = gateway), or

(ii)  a TURN = server behind that firewall/default gateway and opens a path to that = TURN server  

- if the intercepted = allocate request was intended for an application provided TURN server, = the TURN client (e.g. WebRTC browser) on behalf of the user, can select = to:

(iii) only use the auto discovered = TURN server

(iv)  honor an = allocation request by really sending the real-time traffic to the = Application Provided TURN server, using the Recursively Encapsulated = method, unless

(v)   the = TURN  server connected in (ii) already is the Application Provided = TURN server

 

Security wise, the = right party is in charge in all cases.

A TURN server pinpointed by a firewall/router at the default = gateway should always be trusted (no explicit authentication with = credentials is needed) and used. (We trust the default gateway with all = our traffic anyway, and any evil intent to disturb real-time traffic can = in such case be implemented in a default gateway by easier = means.)

 

 

Such = "exo-sealed" configuration should be the default configuration = if a
network provided TURN server is made available for good = (non-evil) purposes.


2) Mobile devices need to work on = various networks, without individual
configuration

I am not = clear about the thoughts behind the "configuration" of sealed = level
and requirements for authentication of the turn server, but if = there are
methods where an enterprise network (LAN) admin can provide = credentials and
force a certain sealed level upon the WebRTC-browser = when used at that LAN,
or if the user has the possibility to = configure manually, I am OK with that
this can and should OVERRIDE = any default configuration or other
configuration (on that particular = network).

However, for mobile devices - Don't we all happily = connect our browsers via
WiFi here and there? - there must be a way = for a network provider with a
good intent to offer an exo-sealed TURN = server that automatically should be
used, e.g. to achieve the purpose = of offering better RTC quality than is
available through the default = gateway WAN path on that network.

A network provided TURN-server = can easily be made available ONLY to the
network users that it is = serving, so there is no need for authentication and
credentials to = protect against illegal usage of a valuable resource, like it
is with = the application provided turn server. Network provided TURN = servers
are simply deployed for the network users to be use without = other
authentication than being granted an IP address and a default = gateway to use
on that particular network in itself.

The same = goes for trusting the TURN server with our real-time traffic - If
we = would trust the same network provider with the same real-time = traffic
through the default gateway - we should also use the offered = TURN server
without other "authentication" than that it is = available on our network:
Data through the default gateway, RTC = through the TURN path is why the TURN
server is provided!

But = do we know that it is not someone with the evil purpose of stealing = our
(encrypted!) real time traffic that is offering the TURN server = (instead of
the network provider), which leads us to my point 3). (If = we really think
there is a risk of and danger with such = attacks...)


3) Is it now good enough to simply use the auto = discovered TURN server? Hope
so!

There has been some recent = improvements to
draft-ietf-tram-turn-server-discovery-03 and = hopefully that is sufficient
for assuming that the auto-discovered = TURN server is offered by our network
provider (a service provider or = the enterprise itself) that we trust anyway,
and the TURN server then = simply shall be used and considered exo-sealed.
(The current RETURN = draft says a non configured TURN server should be
leaky.)

 

The security considerations in that document suggest that = not all discovery mechanisms have equal additional exposure to local = network interference.  I would appreciate clearer guidance on that = front.  It seems to me that DHCP is the only listed mechanism that = creates minimal additional exposure to network = interference.

 

--= - I am addressing TRAM about this and believe that the variant of the = Anycast method I suggest to be added, will fully resolve all security = concerns. I am also suggesting that it is up to this RTCWEB draft to = select from TRAM’s methods and advices for the WebRTC application = and its use cases.

 

--= - See my deployment concerns regarding DHCP put in front of TRAM. I = think that the Anycast method with a short TTL-limitation is good enough = from the privacy aspect, when used to find Border TURN = server.

 

--= - Even though the new variant I propose is more secure and even easier = to deploy, I suggest that this RETURN draft mandates the use of the both = the Anycast method and its new variant. The reason is that already = today, all routers/firewalls at a default gateways can add the anycast = route required for discovery, while intercepting the TURN  allocate = request and responding with the Try Alternate server probably requires a = software upgrade of installed  firewalls and routers with default = gateways (a firewall in front of the default gateway can also do the = interception and response).

 

Some concerns = regarding the DISCOVERY draft and whether these things should
be = specified in the RETURN document:

- Is the above the case with = all discovery methods proposed? Or shall the
RETURN document make one = method mandatory to implement?

- Can that method then be the = Anycast method (which by far seems to be the
most convenient to = deploy and to implement and should work for all network
types and in = all devices operating systems). I think what is said = under
"9.3.  Anycast" under "9.  Security = Considerations" is sufficient for
trusting such discovered TURN = server. What should then go into the RETURN
draft - or should the = DISCOVERY draft be more specific?

I don't fully understand the = DISCOVERY draft's: "... three discovery
mechanisms. The reason = for providing multiple mechanisms is to maximize the
opportunity for = discovery,"

- Can we really put the burden upon all WebRTC = devices to implement all
methods and I doubt network providers will = deploy more than one method. That
seems risking rather than = maximizing discovery...


It is high time to get this done - = can we?

/Karl



-----Ursprungligt = meddelande-----
Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] = F=F6r internet-drafts@ietf.org
Skickat: den 14 maj 2015 00:29
Till: i-d-announce@ietf.org
Kopia: rtcweb@ietf.org
=C4mne: [rtcweb] I-D Action: = draft-ietf-rtcweb-return-00.txt


A New Internet-Draft is = available from the on-line Internet-Drafts
directories.
 This = draft is a work item of the Real-Time Communication in = WEB-browsers
Working Group of the IETF.

      =   Title           : Recursively = Encapsulated TURN (RETURN) for
Connectivity and Privacy in = WebRTC
        Authors        =  : Benjamin M. Schwartz
          =                 Justin = Uberti
        Filename      =   : draft-ietf-rtcweb-return-00.txt
        = Pages           : 18
    =     Date            : = 2015-05-13

Abstract:
   In the context of WebRTC, = the concept of a local TURN proxy has been
   suggested, = but not reviewed in detail.  WebRTC applications are
  =  already using TURN to enhance connectivity and privacy.  = This
   document explains how local TURN proxies and WebRTC = applications can
   work together.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/

There's also a htmlized version = available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-return-00


Please note that it may take a = couple of minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

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

_______________________________________________
r= tcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 

 

 

=

------=_NextPart_000_0227_01D0C262.61A214A0-- From nobody Mon Jul 20 11:08:00 2015 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 68A2C1B2A6B; Mon, 20 Jul 2015 11:07:57 -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 KlfQjNzMwxvn; Mon, 20 Jul 2015 11:07:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 634F61B2A57; Mon, 20 Jul 2015 11:07:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720180753.18424.83272.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 11:07:53 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-04.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: Mon, 20 Jul 2015 18:07:57 -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 : TURN Server Auto Discovery Authors : Prashanth Patil Tirumaleswar Reddy Dan Wing Filename : draft-ietf-tram-turn-server-discovery-04.txt Pages : 14 Date : 2015-07-20 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, ISP, or 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 three such mechanisms for TURN server discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-04 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 Mon Jul 20 11:10:44 2015 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 4C68D1B2A3D for ; Mon, 20 Jul 2015 11:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LOBRiHMMrYK for ; Mon, 20 Jul 2015 11:10:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0AD31A1B2E for ; Mon, 20 Jul 2015 11:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2085; q=dns/txt; s=iport; t=1437415841; x=1438625441; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=R1rjcohJE0m/GVxGUSpbH9QxppnswFp9D9MyTla6Ppo=; b=Z+C4rTyQ5Bj8IAuPCpHlOKAyd0dgWs95lnlLjQS5O8jFWGg+eG0fOVIX IJqjthTdmTM/k6cGajvAqmlaJyZsqOP2UATNSIy5n8Q7TIpnITW+Q4AI+ eD94W1IXUTBhiXFCTF9MY+JPS6UbAGhhWJC3PgrslIkUVUSazCCM+cP53 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwCVOK1V/5RdJa1cgxNUaQa7ZwmBawyFfwKBLzgUAQEBAQEBAYEKhCQBAQQBAQFrGwIBCEYnCyUCBBOILg3IRAEBAQEBAQEDAQEBAQEBARuLTIQtDhg6hCsFjHCHYgGEbocygUNGg1STKiaDfG+BBEOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,509,1432598400"; d="scan'208";a="11439006" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 20 Jul 2015 18:10:40 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6KIAeVS002569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 18:10:40 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.32]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 13:10:40 -0500 From: "Prashanth Patil (praspati)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-04.txt Thread-Index: AQHQwxdiUKy8ScNhX0i8DGERA14sHw== Date: Mon, 20 Jul 2015 18:10:39 +0000 Message-ID: References: <20150720180753.18424.83272.idtracker@ietfa.amsl.com> In-Reply-To: <20150720180753.18424.83272.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.5.2.150604 x-originating-ip: [10.155.85.182] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6EA0935CB4609E4585D478E921298329@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-04.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, 20 Jul 2015 18:10:43 -0000 The revision addresses Ted=B9s comments during WGLC. -Prashanth On 7/20/15, 11:07 AM, "tram on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the TURN Revised and Modernized Working >Group of the IETF. > > Title : TURN Server Auto Discovery > Authors : Prashanth Patil > Tirumaleswar Reddy > Dan Wing > Filename : draft-ietf-tram-turn-server-discovery-04.txt > Pages : 14 > Date : 2015-07-20 > >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, > ISP, or 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 three such mechanisms for > TURN server discovery. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-04 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-server-discovery-= 04 > > >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/ > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Mon Jul 20 16:11:37 2015 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 EBA9F1AC3F7 for ; Mon, 20 Jul 2015 16:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 tTs0QDkdBRb4 for ; Mon, 20 Jul 2015 16:11:33 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE47B1AC3F3 for ; Mon, 20 Jul 2015 16:11:32 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6KNBW1r019279 for ; Mon, 20 Jul 2015 19:11:32 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1vndj4awbb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Jul 2015 19:11:32 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 18:11:30 -0500 From: Jonathan Lennox To: "tram@ietf.org" Thread-Topic: Comments on draft-ietf-tram-stunbis-04 Thread-Index: AQHQw0FpKDSNT4EV4kOanzx1vywBBw== Date: Mon, 20 Jul 2015 23:11:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.15.250] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_03:2015-07-20,2015-07-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200378 Archived-At: Subject: [tram] Comments on draft-ietf-tram-stunbis-04 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, 20 Jul 2015 23:11:36 -0000 SW5zcGlyZWQgYnkgdGhlIHBsZWFzIGluIHRoZSBUUkFNIHdvcmtpbmcgZ3JvdXAgdG9kYXksIEkg ZGVjaWRlZCByZWFkIG92ZXIgZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMDQuDQoNCihOb3RlIHRo YXQgSeKAmXZlIG9ubHkgcmV2aWV3ZWQgdGhlIGRpZmYgZnJvbSBSRkMgNTM4OSwgbm90IHJlLXJl YWRpbmcgdGhlIGRvY3VtZW50IGZyb20gc2NyYXRjaCwgc28gdGhpcyBvbmx5IGNhdGNoZXMgbmV3 IHByb2JsZW1zLCBub3Qgb2xkIHByb2JsZW1zLikNCg0KU2VjdGlvbiA4LjE6ICJUaGUgRE5TIFNS ViBzZXJ2aWNlIG5hbWUgaXMgdGhlIGNvbnRlbnQgb2YgdGhlIDxob3N0PiBwYXJ0LuKAnQ0KVGhp cyBpcyB3cm9uZyDigJQgdGhlIEROUyBTUlYgc2VydmljZSBuYW1lIGlzIOKAnHN0dW7igJ0gb3Ig 4oCcc3R1bnPigJ0uICBUaGlzIHNlZW1zIHRvIGhhdmUgZ290dGVuIG1hbmdsZWQgaW4gdGhlIGNv bnZlcnNpb24gdG8gZGVzY3JpYmluZyB0aGUgcmVzb2x1dGlvbiBwcm9jZXNzIGluIHRlcm1zIG9m IHRoZSBVUkwuDQoNClNlY3Rpb24gOS4xLjM6DQoNCuKAnElmIHRoZSBNRVNTQUdFLUlOVEVHUklU WS1TSEEyNTYgYXR0cmlidXRlIGlzIHByZXNlbnQgY29tcHV0ZSB0aGUJDQp2YWx1ZSBmb3IgdGhl IG1lc3NhZ2UgaW50ZWdyaXR5IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDE0LjUsCQ0KdXNpbmcg dGhlIHBhc3N3b3JkIGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlcm5hbWUuIElmIHRoZSBNRVNTQUdF LQkNCklOVEVHUklUWS1TSEEyNTYgYXR0cmlidXRlIGlzIG5vdCBwcmVzZW50LCBhbmQgdXNpbmcg dGhlIHNhbWUJDQpwYXNzd29yZCwgY29tcHV0ZSB0aGUgdmFsdWUgZm9yIHRoZSBtZXNzYWdlIGlu dGVncml0eSBhcyBkZXNjcmliZWQJDQppbiBTZWN0aW9uIDE0LjQuIElmIHRoZSByZXN1bHRpbmcg dmFsdWUgZG9lcyBub3QgbWF0Y2ggdGhlCQ0KY29udGVudHMgb2YgdGhlIE1FU1NBR0UtSU5URUdS SVRZLVNIQTI1NiBhdHRyaWJ1dGUgb3IgdGhlIE1FU1NBR0UtCQ0KSU5URUdSSVRZIGF0dHJpYnV0 ZTrigJ0NCg0KSXMgdGhpcyBzYXlpbmcgdGhhdCBhIFNIQS0xIG1lc3NhZ2UgaW50ZWdyaXR5IHZh bHVlIChkZXNjcmliZWQgaW4gU2VjdGlvbiAxNC40KSBjYW4gYmUgY2FycmllZCBpbiBhIE1FU1NB R0UtSU5URUdSSVRZLVNIQTI1NiBhdHRyaWJ1dGU/ICBUaGF0IGRvZXNu4oCZdCBzZWVtIHJpZ2h0 Lg0KDQpTZWN0aW9uIDkuMS40Og0KDQrigJxUaGUgY2xpZW50IGxvb2tzIGZvciB0aGUgTUVTU0FH RS1JTlRFR1JJVFktU0hBMjU2IG9yIHRoZSBNRVNTQUdFLQkNCklOVEVHUklUWSBhdHRyaWJ1dGUg aW4gdGhlIHJlc3BvbnNlLiBJZiBwcmVzZW50LCB0aGUgY2xpZW50IGNvbXB1dGVzCQ0KdGhlIG1l c3NhZ2UgaW50ZWdyaXR5IG92ZXIgdGhlIHJlc3BvbnNlIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAx NC40IG9yCQ0KU2VjdGlvbiAxNC41LCB1c2luZyB0aGUgc2FtZSBwYXNzd29yZCBpdCB1dGlsaXpl ZCBmb3IgdGhlIHJlcXVlc3QuCQ0KSWYgdGhlIHJlc3VsdGluZyB2YWx1ZSBtYXRjaGVzIHRoZSBj b250ZW50cyBvZiB0aGUgTUVTU0FHRS1JTlRFR1JJVFkJDQpvciBNRVNTQUdFLUlOVEVHUklUWS1T SEEyNTYgYXR0cmlidXRlLCB0aGUgcmVzcG9uc2UgaXMgY29uc2lkZXJlZAkNCmF1dGhlbnRpY2F0 ZWQuIElmIHRoZSB2YWx1ZSBkb2VzIG5vdCBtYXRjaCwgb3IgaWYgYm90aCBNRVNTQUdFLQkNCklO VEVHUklUWSBhbmQgTUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2IHdlcmUgYWJzZW50LCB0aGUgcmVz cG9uc2UgTVVTVAkNCmJlIGRpc2NhcmRlZCwgYXMgaWYgaXQgd2FzIG5ldmVyIHJlY2VpdmVkLiBU aGlzIG1lYW5zIHRoYXQJDQpyZXRyYW5zbWl0cywgaWYgYXBwbGljYWJsZSwgd2lsbCBjb250aW51 ZS7igJ0NCg0KUGFyYWxsZWxpc20gZmFpbHVyZS4gU29tZXRpbWVzIE1FU1NBR0UtSU5URUdSSVRZ IGlzIGxpc3RlZCBmaXJzdCwgYW5kIHNvbWV0aW1lcyBNRVNTQUdFLUlOVEVHUklUWS1TSEEyNTYu ICBJZiByZWFkIGxpdGVyYWxseSBpdCB3b3VsZCBzZWVtIHRvIGltcGx5IHlvdSB3ZXJlIHN3YXBw aW5nIHRoZSB2YWx1ZXMuICBUaGUgdHdvIGFsZ29yaXRobXMgc2hvdWxkIGJlIGNvbnNpc3RlbnRs eSBsaXN0ZWQgaW4gb3JkZXIsIGFuZCBpdCBzaG91bGQgYmUgbWFkZSBjbGVhciB0aGF0IHRoZXkg YXBwbHkgcmVzcGVjdGl2ZWx5Lg0KDQpBZGRpdGlvbmFsbHksIGl0IHNob3VsZCBzYXkgdGhhdCBp ZiB0aGUgY2xpZW50IG9ubHkgc2VudCBvbmUgYWxnb3JpdGhtIGluIHRoZSByZXF1ZXN0IChiZWNh dXNlIG9mIHRoZSBleHRlcm5hbCBpbmRpY2F0aW9uIGluIHNlY3Rpb24gOS4xLjIsIG9yIHRoaXMg YmVpbmcgYSBzdWJzZXF1ZW50IHJlcXVlc3QgYXMgZGVmaW5lZCBpbiA5LjEuNSkgdGhlIGFsZ29y aXRobSBpbiB0aGUgcmVzcG9uc2UgaGFzIHRvIG1hdGNoLg0KDQpTZWN0aW9uIDkuMS41Og0KDQri gJxBIGNsaWVudCBzZW5kaW5nIHN1YnNlcXVlbnQgcmVxdWVzdHMgdG8gdGhlIHNhbWUgc2VydmVy IGEgTUFZIGNob29zZQkNCnRvIHNlbmQgb25seSB0aGUgTUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2 IG9yIHRoZSBNRVNTQUdFLUlOVEVHUklUWQkNCmF0dHJpYnV0ZSBkZXBlbmRpbmcgdXBvbiB0aGUg YXR0cmlidXRlIHRoYXQgd2FzIHJlY2VpdmVkIGluIHRoZQkNCnJlc3BvbnNlIHRvIHRoZSBpbml0 aWFsIHJlcXVlc3Qu4oCdDQoNClRoaXMgc2hvdWxkIHByb2JhYmx5IGJlIHJlcXVpcmVkIHRvIGJl IHRoZSBsaXRlcmFsIHNhbWUgc2VydmVyIOKAlGkuZS4sIHRoZSBzYW1lIElQIGFuZCBwb3J0IOKA lCBub3QganVzdCB0aGUgc2FtZSBVUkwgb3IgU1JWIGxvb2t1cC4NCg0KU2VjdGlvbiA5LjIuMzoN Cg0KVGhlcmUgc2VlbXMgdG8gYmUgYSByYW5kb20gZ2l0aHViIFVSTCBwYXN0ZWQgaW50byB0aGUg ZG9jdW1lbnQuDQoNCuKAnElmIHRoZSBOT05DRSBhdHRyaWJ1dGUgc3RhcnRzIHdpdGggdGhlIHZh bHVlICJvYk1hdEpvczIiIGJ1dCB0aGUJDQpQQVNTV09SRC1BTEdPUklUSE1TIGF0dHJpYnV0ZSBp cyBub3QgcHJlc2VudCBvciBpcyBub3QgaWRlbnRpY2FsCQ0KdG8gdGhlIFBBU1NXT1JELUFMR09S SVRITVMgYXR0cmlidXRlIHNlbnQgaW4gdGhlIHJlc3BvbnNlLCB0aGUJDQpzZXJ2ZXIgTVVTVCBn ZW5lcmF0ZSBhbiBlcnJvciByZXNwb25zZSB3aXRoIGFuIGVycm9yIGNvZGUgb2YgNDAwCQ0KKEJh ZCBSZXF1ZXN0KS4gVGhpcyByZXNwb25zZSBTSE9VTEQgTk9UIGluY2x1ZGUgYSBVU0VSTkFNRSwJ DQpOT05DRSwgUkVBTE0sIE1FU1NBR0UtSU5URUdSSVRZLCBvciBNRVNTQUdFLUlOVEVHUklUWS1T SEEyNTYJDQphdHRyaWJ1dGUu4oCdDQoNCkRvZXNu4oCZdCB0aGlzIGJyZWFrIGJhY2t3YXJkIGNv bXBhdGliaWxpdHkgd2l0aCBSRkMgNTM4OSAoaS5lLiwgTUQ1LWFsZ29yaXRobS1vbmx5KSBjbGll bnRzPyAgSXTigJlzIGEgc2VydmVy4oCZcyBjaG9pY2Ugd2hldGhlciB0byBzdXBwb3J0IE1ENSBh cyBhIHBhc3N3b3JkIGFsZ29yaXRobSwgYnV0IHByZXN1bWFibHkgaWYgaXQgZG9lcyBpdOKAmXMg ZG9pbmcgc28gZm9yIGEgcmVhc29uIChpLmUuIGFuIG9sZCBwYXNzd29yZCBkYXRhYmFzZSBvciBz dXBwb3J0aW5nIG9sZCBjbGllbnRzKS4NCg0KSSB0aGluayB0aGlzIHNob3VsZCBzYXkgdGhhdCBp ZiBQQVNTV09SRC1BTEdPUklUSE1TIGRvZXNu4oCZdCBtYXRjaCwgdGhlIHJlcXVlc3QgaXMgZHJv cHBlZDsgYnV0IGlmIHRoZSByZXF1ZXN0IGNvbnRhaW5zIG5laXRoZXIgUEFTU1dPUkQtQUxHT1JJ VEhNUyBub3IgUEFTU1dPUkQtQUxHT1JJVEhNLCB0aGUgcmVxdWVzdCBpcyBwcm9jZXNzZWQgYXMg dGhvdWdoIFBBU1NXT1JELUFMR09SSVRITSB3ZXJlIE1ENS4gIChBbmQgTUQ1IHNob3VsZCBiZSBh ZGRlZCB0byBQQVNTV09SRC1BTEdPUklUSE1TLCBzZWUgYmVsb3cuKSAgRGVwZW5kaW5nIG9uIHRo ZSBsaXN0IGluIFBBU1NXT1JELUFMR09SSVRITVMsIHRoaXMgbWF5IGVpdGhlciBiZSBzdXBwb3J0 ZWQsIG9yIHRyaWdnZXIgYSA0MDAuDQoNCkl04oCZcyBhIDQwMCBpZiBvbmx5IG9uZSBvZiBQQVNT V09SRC1BTEdPUklUSE0gb3IgUEFTU1dPUkQtQUxHT1JJVEhNUyBpcyBwcmVzZW50LCBvciBpZiBQ QVNTV09SRC1BTEdPUklUSE0gZG9lc27igJl0IG1hdGNoIG9uZSBvZiB0aGUgZW50cmllcyBpbiBQ QVNTV09SRC1BTEdPUklUSE1TLg0KDQpNZWFud2hpbGUsIHRvIHByZXZlbnQgYmlkLWRvd24sIHRo ZSAqY2xpZW50KiByZXF1aXJlbWVudHMgc2hvdWxkIHNheSB0aGF0IGlmIHRoZSBub25jZSBiZWdp bnMgd2l0aCBvYk1hdEpvczIgYnV0IFBBU1NXT1JELUFMR09SSVRITVMgaXMgbm90IHByZXNlbnQs IHRoZSByZXNwb25zZSBzaG91bGQgYmUgaWdub3JlZC4NCg0KDQrigJxJZiB0aGVzZSBjaGVja3Mg cGFzcywgdGhlIHNlcnZlciBjb250aW51ZXMgdG8gcHJvY2VzcyB0aGUgcmVxdWVzdC4JDQpBbnkg cmVzcG9uc2UgZ2VuZXJhdGVkIGJ5IHRoZSBzZXJ2ZXIgKGV4Y2VwdGluZyB0aGUgY2FzZXMgZGVz Y3JpYmVkCQ0KYWJvdmUpIE1VU1QgaW5jbHVkZSBib3RoIHRoZSBNRVNTQUdFLUlOVEVHUklUWSBh bmQgTUVTU0FHRS1JTlRFR1JJVFktCQ0KU0hBMjU2IGF0dHJpYnV0ZXMsIGNvbXB1dGVkIHVzaW5n IHRoZSB1c2VybmFtZSBhbmQgcGFzc3dvcmQgdXRpbGl6ZWQJDQp0byBhdXRoZW50aWNhdGUgdGhl IHJlcXVlc3Qu4oCdDQoNCldoeSBkbyB5b3Ugd2FudCBib3RoPyAgRm9yIHNob3J0LXRlcm0geW91 IG9ubHkgc2VuZCBNRVNTQUdFLUlOVEVHUklUWS1TSEEyNTYgaWYgdGhlIGNsaWVudCBzdXBwb3J0 ZWQgaXQuDQoNClNlY3Rpb24gOS4yLjQ6DQoNCuKAnElmIHRoZSByZXNwb25zZSBpcyBhbiBlcnJv ciByZXNwb25zZSB3aXRoIGFuIGVycm9yIGNvZGUgb2YgNDAxCQ0KKFVuYXV0aG9yaXplZCksIHRo ZSBjbGllbnQgU0hPVUxEIHJldHJ5IHRoZSByZXF1ZXN0IHdpdGggYSBuZXcJDQp0cmFuc2FjdGlv bi4gVGhpcyByZXF1ZXN0IE1VU1QgY29udGFpbiBhIFVTRVJOQU1FLCBkZXRlcm1pbmVkIGJ5IHRo ZQkNCmNsaWVudCBhcyB0aGUgYXBwcm9wcmlhdGUgdXNlcm5hbWUgZm9yIHRoZSBSRUFMTSBmcm9t IHRoZSBlcnJvcgkNCnJlc3BvbnNlLiBUaGUgcmVxdWVzdCBNVVNUIGNvbnRhaW4gdGhlIFJFQUxN LCBjb3BpZWQgZnJvbSB0aGUgZXJyb3IJDQpyZXNwb25zZS4gVGhlIHJlcXVlc3QgTVVTVCBjb250 YWluIHRoZSBOT05DRSwgY29waWVkIGZyb20gdGhlIGVycm9yCQ0KcmVzcG9uc2UuIElmIHRoZSBy ZXNwb25zZSBjb250YWlucyBhIFBBU1NXT1JELUFMR09SSVRITVMgYXR0cmlidXRlLAkNCnRoZSBy ZXF1ZXN0IE1VU1QgY29udGFpbiB0aGUgUEFTU1dPUkQtQUxHT1JJVEhNUyBhdHRyaWJ1dGUgd2l0 aCB0aGUJDQpzYW1lIGNvbnRlbnQuIElmIHRoZSByZXNwb25zZSBjb250YWlucyBhIFBBU1NXT1JE LUFMR09SSVRITVMJDQphdHRyaWJ1dGUsIGFuZCB0aGlzIGF0dHJpYnV0ZSBjb250YWlucyBhdCBs ZWFzdCBvbmUgYWxnb3JpdGhtIHRoYXQgaXMJDQpzdXBwb3J0ZWQgYnkgdGhlIGNsaWVudCB0aGVu IHRoZSByZXF1ZXN0IE1VU1QgY29udGFpbiBhIFBBU1NXT1JELQkNCkFMR09SSVRITSBhdHRyaWJ1 dGUgd2l0aCB0aGUgZmlyc3QgYWxnb3JpdGhtIHN1cHBvcnRlZCBvbiB0aGUgbGlzdC7igJ0NCg0K VGhpcyB0ZXh0IHNlZW1zIHRvIGltcGx5IHRoYXQgaWYgdGhlIFBBU1NXT1JELUFMR09SSVRITVMg bGlzdCBjb250YWlucyBvbmx5IGFsZ29yaXRobXMgdGhlIGNsaWVudCBkb2VzbuKAmXQgcmVjb2du aXplLCB0aGUgY2xpZW50IGdvZXMgYWhlYWQgYW5kIHVzZXMgTUQ1LiBEb2VzIHRoaXMgbWFrZSBz ZW5zZT8gSSB0aGluayB0aGUgY2xpZW50IHNob3VsZCBnaXZlIHVwIGlmIGl0IGRvZXNu4oCZdCBz dXBwb3J0IGFueSBvZiB0aGUgYWxnb3JpdGhtcy4gDQoNCiJpZiB0aGUgcmVzcG9uc2UgY29udGFp bnMgYSBNRVNTQUdFLUlOVEVHUklUWS1TSEEyNTYgYXR0cmlidXRlIHRoZW4JDQp0aGUgcmVxdWVz dCBNVVNUIGNvbnRhaW4gYSBNRVNTQUdFLUlOVEVHUklUWS1TSEEyNTYgYXR0cmlidXRlLAkNCmNv bXB1dGVkIHVzaW5nIHRoZSBwYXNzd29yZCBhc3NvY2lhdGVkIHdpdGggdGhlIHVzZXJuYW1lIGlu IHRoZQkNClVTRVJOQU1FIGF0dHJpYnV0ZS4gRWxzZSB0aGUgcmVxdWVzdCBNVVNUIGNvbnRhaW4g dGhlIE1FU1NBR0UtCQ0KSU5URUdSSVRZIGF0dHJpYnV0ZSwgY29tcHV0ZWQgdXNpbmcgdGhlIHBh c3N3b3JkIGFzc29jaWF0ZWQgd2l0aCB0aGUJDQp1c2VybmFtZSBpbiB0aGUgVVNFUk5BTUUgYXR0 cmlidXRlLiBUaGUgY2xpZW50IE1VU1QgTk9UIHBlcmZvcm0gdGhpcwkNCnJldHJ5IGlmIGl0IGlz IG5vdCBjaGFuZ2luZyB0aGUgVVNFUk5BTUUgb3IgUkVBTE0gb3IgaXRzIGFzc29jaWF0ZWQJDQpw YXNzd29yZCwgZnJvbSB0aGUgcHJldmlvdXMgYXR0ZW1wdC7igJ0NCg0KV2XigJlyZSBzdGlsbCB0 YWxraW5nIGFib3V0IHRoZSA0MDEgVW5hdXRob3JpemVkIGhlcmUsIHJpZ2h0PyBUaGUgdGV4dCBz YXlzIHRoZSByZXNwb25zZSBTSE9VTEQgTk9UIGNvbnRhaW4gTUVTU0FHRS1JTlRFR1JJVFktU0hB MjU2LCBzaW5jZSB0aGVyZeKAmXMgbm8gd2F5IHRvIGtub3cgdGhlIHVzZXJuYW1lIHRvIHVzZS4N Cg0KVGhhdCBzYWlkLCBpdCBzZWVtcyB0byBtZSB0byBiZSByZWFzb25hYmxlIHRvIHNheSB0aGF0 IGlmIHRoZSByZXNwb25zZSBjb250YWlucyBQQVNTV09SRC1BTEdPUklUSE1TLCB0aGUgZm9sbG93 dXAgcmVxdWVzdCBzaG91bGQgYmUgYXV0aGVudGljYXRlZCB1c2luZyBNRVNTQUdFLUlOVEVHUklU WS1TSEEyNTYgb25seSwgc2luY2Ugd2Uga25vdyB0aGF0IGJvdGggdGhlIGNsaWVudCBhbmQgc2Vy dmVyIGFyZSBzdHVuYmlzLg0KDQoNCg0KU2VjdGlvbiAxNC4xMDoNCg0K4oCcVGhlIFBBU1NXT1JE LUFMR09SSVRITVMgYXR0cmlidXRlIGlzIHByZXNlbnQgb25seSBpbiByZXNwb25zZXMu4oCdDQoN Ck5vdCB0cnVlLCBpdOKAmXMgaW4gZm9sbG93dXAgcmVxdWVzdHMsIGFzIG1lbnRpb25lZCwgdG8g cHJldmVudCBiaWQtZG93bi4NCg0KU2VjdGlvbiAxNy40Og0KDQpTYWx0ZWQgU0hBLTI1NiBpcyBz dGlsbCBsaXN0ZWQgaW4gdGhlIHBhc3N3b3JkIGFsZ29yaXRobXMgdGFibGUsIGRlc3BpdGUgYmVp bmcgb3RoZXJ3aXNlIGRlbGV0ZWQgZnJvbSB0aGUgZG9jdW1lbnQuDQoNClNob3VsZCB3ZSBkZWZp bmUgTUQ1IGFzIGEgUEFTU1dPUkQtQUxHT1JJVEhNIHZhbHVlPyBUaGUgdXNlIGNhc2UgaXMgYSBz ZXJ2ZXIgdGhhdCB3YW50cyB0byB1cGdyYWRlIHRvIHN0dW5iaXMsIGJ1dCB3YW50cyB0byBrZWVw IHVzaW5nIGl0cyBleGlzdGluZyAobWQ1LWhhc2hlZCkgcGFzc3dvcmQgZGF0YWJhc2Ugd2l0aG91 dCBmb3JjaW5nIHVzZXJzIHRvIHJlLWVudGVyIHRoZWlyIHBhc3N3b3JkLiAgKFRoaXMgd291bGQg bWVhbiBhIGNhc2Ugd2hlcmUgbG9uZy10ZXJtIGF1dGhlbnRpY2F0aW9uIHVzZXMgdGhlIE1ENSBw YXNzd29yZCBhbGdvcml0aG0sIGJ1dCBNRVNTQUdFLUlOVEVHUklUWS1TSEEyNTYgaW50ZWdyaXR5 LikNCg0KDQpTZWN0aW9uIDE3LjU6DQoNClNob3VsZCByZWdpc3RlciB0aGUgc3R1bnMgb3ZlciBV RFAgcG9ydC4NCg0KDQpBIGdlbmVyYWwgcXVlc3Rpb24gYWJvdXQgdGhlIFBBU1NXT1JELUFMR09S SVRITSB0cmFuc2l0aW9uIHByb2Nlc3M6IGRvIHdlIHdhbnQgdG8gc3VwcG9ydCB0aGUgdXNlIGNh c2Ugd2hlcmUgYSBzZXJ2ZXIgaXMgZ3JhZHVhbGx5IHRyYW5zaXRpb25pbmcgaXRzIGV4aXN0aW5n IGRhdGFiYXNlIHRvIGhhdmUgU0hBLTI1NiBhcyB0aGUgcGFzc3dvcmQgaGFzaCBhbGdvcml0aG0g KGFzIHVzZXJzIGNoYW5nZSBwYXNzd29yZHMpPyAgVGhpcyBtaWdodCByZXN1bHQgaW4gYSBjYXNl IHdoZXJlIHNvbWUgdXNlcnMgaGF2ZSBNRDUtaGFzaGVkIHBhc3N3b3JkcyBpbiB0aGUgZGF0YWJh c2UsIGFuZCBzb21lIGhhdmUgU0hBLTI1NiDigJQgYnV0IHRoZSBzZXJ2ZXIgZG9lc27igJl0IHll dCBrbm93IHdoZW4gcmVzcG9uZGluZyB0byB0aGUgaW5pdGlhbCByZXF1ZXN0IHdoaWNoIHVzZXIg aXMgbWFraW5nIHRoZSByZXF1ZXN0LCBhbmQgdGh1cyB3aGljaCBwYXNzd29yZCBhbGdvcml0aG1z IGFyZSBhY3R1YWxseSBzdXBwb3J0ZWQgZm9yIHRoaXMgc3BlY2lmaWMgdXNlci4gIFN1cHBvcnRp bmcgdGhpcyB3b3VsZCByZXF1aXJlIGVpdGhlciBwdXR0aW5nIFVTRVJOQU1FIGluIHRoZSBpbml0 aWFsIHJlcXVlc3QgKHdoaWNoIHNlZW1zIGJhZCBpbiB0aGUgYWJzZW5jZSBvZiBhIGtub3duIHJl YWxtKSwgb3IgZWxzZSBhbGxvd2luZyBhIHNlcnZlciB0byByZXNwb25kIHRvIGEgZm9sbG93dXAg cmVxdWVzdCB3aXRoIGFub3RoZXIgNDAxIFVuYXV0aG9yaXplZCByZXNwb25zZSwgd2l0aCBhIHNo b3J0ZXIgUEFTU1dPUkQtQUxHT1JJVEhNUyBsaXN0IChyZXN1bHRpbmcgaW4gbG9uZy10ZXJtIGF1 dGhlbnRpY2F0aW9uIHJlcXVpcmluZyB0aHJlZSB0cmFuc2FjdGlvbnMgZm9yIHN0dW5iaXMgY2xp ZW50cyB3aG9zZSB1c2VycyB3aG8gYXJlIHN0aWxsIG9uIE1ENSkuICBEZXNwaXRlIHRoZSB0cmlw bGUgdHJhbnNhY3Rpb24sIEnigJltIGluY2xpbmVkIHRvIHJlY29tbWVuZCB0aGUgbGF0dGVyLg0K DQoNCg0K From nobody Mon Jul 20 20:12:42 2015 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 EC7EC1ACDD2 for ; Mon, 20 Jul 2015 20:12:40 -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 Dkb9aLgnQuIR for ; Mon, 20 Jul 2015 20:12:38 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6D43D1ACDCF for ; Mon, 20 Jul 2015 20:12:36 -0700 (PDT) Received: from [IPv6:2001:df8:ffff:6:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:ffff:6:ca0a:a9ff:fe2e:a4f6]) (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 75B31204FA; Tue, 21 Jul 2015 05:12:35 +0200 (CEST) Message-ID: <55ADB8A1.2000606@acm.org> Date: Tue, 21 Jul 2015 05:12:33 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Jonathan Lennox , "tram@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Comments on draft-ietf-tram-stunbis-04 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, 21 Jul 2015 03:12:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/21/2015 01:11 AM, Jonathan Lennox wrote: > Inspired by the pleas in the TRAM working group today, I decided read over draft-ietf-tram-stunbis-04. Thanks for the review, it is much appreciated. I will work diligently on this as soon I am back from Europe. > > (Note that I’ve only reviewed the diff from RFC 5389, not re-reading the document from scratch, so this only catches new problems, not old problems.) > > Section 8.1: "The DNS SRV service name is the content of the part.†> This is wrong — the DNS SRV service name is “stun†or “stunsâ€. This seems to have gotten mangled in the conversion to describing the resolution process in terms of the URL. > > Section 9.1.3: > > “If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the > value for the message integrity as described in Section 14.5, > using the password associated with the username. If the MESSAGE- > INTEGRITY-SHA256 attribute is not present, and using the same > password, compute the value for the message integrity as described > in Section 14.4. If the resulting value does not match the > contents of the MESSAGE-INTEGRITY-SHA256 attribute or the MESSAGE- > INTEGRITY attribute:†> > Is this saying that a SHA-1 message integrity value (described in Section 14.4) can be carried in a MESSAGE-INTEGRITY-SHA256 attribute? That doesn’t seem right. > > Section 9.1.4: > > “The client looks for the MESSAGE-INTEGRITY-SHA256 or the MESSAGE- > INTEGRITY attribute in the response. If present, the client computes > the message integrity over the response as defined in Section 14.4 or > Section 14.5, using the same password it utilized for the request. > If the resulting value matches the contents of the MESSAGE-INTEGRITY > or MESSAGE-INTEGRITY-SHA256 attribute, the response is considered > authenticated. If the value does not match, or if both MESSAGE- > INTEGRITY and MESSAGE-INTEGRITY-SHA256 were absent, the response MUST > be discarded, as if it was never received. This means that > retransmits, if applicable, will continue.†> > Parallelism failure. Sometimes MESSAGE-INTEGRITY is listed first, and sometimes MESSAGE-INTEGRITY-SHA256. If read literally it would seem to imply you were swapping the values. The two algorithms should be consistently listed in order, and it should be made clear that they apply respectively. > > Additionally, it should say that if the client only sent one algorithm in the request (because of the external indication in section 9.1.2, or this being a subsequent request as defined in 9.1.5) the algorithm in the response has to match. > > Section 9.1.5: > > “A client sending subsequent requests to the same server a MAY choose > to send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY > attribute depending upon the attribute that was received in the > response to the initial request.†> > This should probably be required to be the literal same server —i.e., the same IP and port — not just the same URL or SRV lookup. > > Section 9.2.3: > > There seems to be a random github URL pasted into the document. > > “If the NONCE attribute starts with the value "obMatJos2" but the > PASSWORD-ALGORITHMS attribute is not present or is not identical > to the PASSWORD-ALGORITHMS attribute sent in the response, the > server MUST generate an error response with an error code of 400 > (Bad Request). This response SHOULD NOT include a USERNAME, > NONCE, REALM, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 > attribute.†> > Doesn’t this break backward compatibility with RFC 5389 (i.e., MD5-algorithm-only) clients? It’s a server’s choice whether to support MD5 as a password algorithm, but presumably if it does it’s doing so for a reason (i.e. an old password database or supporting old clients). > > I think this should say that if PASSWORD-ALGORITHMS doesn’t match, the request is dropped; but if the request contains neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM, the request is processed as though PASSWORD-ALGORITHM were MD5. (And MD5 should be added to PASSWORD-ALGORITHMS, see below.) Depending on the list in PASSWORD-ALGORITHMS, this may either be supported, or trigger a 400. > > It’s a 400 if only one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, or if PASSWORD-ALGORITHM doesn’t match one of the entries in PASSWORD-ALGORITHMS. > > Meanwhile, to prevent bid-down, the *client* requirements should say that if the nonce begins with obMatJos2 but PASSWORD-ALGORITHMS is not present, the response should be ignored. > > > “If these checks pass, the server continues to process the request. > Any response generated by the server (excepting the cases described > above) MUST include both the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- > SHA256 attributes, computed using the username and password utilized > to authenticate the request.†> > Why do you want both? For short-term you only send MESSAGE-INTEGRITY-SHA256 if the client supported it. > > Section 9.2.4: > > “If the response is an error response with an error code of 401 > (Unauthorized), the client SHOULD retry the request with a new > transaction. This request MUST contain a USERNAME, determined by the > client as the appropriate username for the REALM from the error > response. The request MUST contain the REALM, copied from the error > response. The request MUST contain the NONCE, copied from the error > response. If the response contains a PASSWORD-ALGORITHMS attribute, > the request MUST contain the PASSWORD-ALGORITHMS attribute with the > same content. If the response contains a PASSWORD-ALGORITHMS > attribute, and this attribute contains at least one algorithm that is > supported by the client then the request MUST contain a PASSWORD- > ALGORITHM attribute with the first algorithm supported on the list.†> > This text seems to imply that if the PASSWORD-ALGORITHMS list contains only algorithms the client doesn’t recognize, the client goes ahead and uses MD5. Does this make sense? I think the client should give up if it doesn’t support any of the algorithms. > > "if the response contains a MESSAGE-INTEGRITY-SHA256 attribute then > the request MUST contain a MESSAGE-INTEGRITY-SHA256 attribute, > computed using the password associated with the username in the > USERNAME attribute. Else the request MUST contain the MESSAGE- > INTEGRITY attribute, computed using the password associated with the > username in the USERNAME attribute. The client MUST NOT perform this > retry if it is not changing the USERNAME or REALM or its associated > password, from the previous attempt.†> > We’re still talking about the 401 Unauthorized here, right? The text says the response SHOULD NOT contain MESSAGE-INTEGRITY-SHA256, since there’s no way to know the username to use. > > That said, it seems to me to be reasonable to say that if the response contains PASSWORD-ALGORITHMS, the followup request should be authenticated using MESSAGE-INTEGRITY-SHA256 only, since we know that both the client and server are stunbis. > > > > Section 14.10: > > “The PASSWORD-ALGORITHMS attribute is present only in responses.†> > Not true, it’s in followup requests, as mentioned, to prevent bid-down. > > Section 17.4: > > Salted SHA-256 is still listed in the password algorithms table, despite being otherwise deleted from the document. > > Should we define MD5 as a PASSWORD-ALGORITHM value? The use case is a server that wants to upgrade to stunbis, but wants to keep using its existing (md5-hashed) password database without forcing users to re-enter their password. (This would mean a case where long-term authentication uses the MD5 password algorithm, but MESSAGE-INTEGRITY-SHA256 integrity.) > > > Section 17.5: > > Should register the stuns over UDP port. > > > A general question about the PASSWORD-ALGORITHM transition process: do we want to support the use case where a server is gradually transitioning its existing database to have SHA-256 as the password hash algorithm (as users change passwords)? This might result in a case where some users have MD5-hashed passwords in the database, and some have SHA-256 — but the server doesn’t yet know when responding to the initial request which user is making the request, and thus which password algorithms are actually supported for this specific user. Supporting this would require either putting USERNAME in the initial request (which seems bad in the absence of a known realm), or else allowing a server to respond to a followup request with another 401 Unauthorized response, with a shorter PASSWORD-ALGORITHMS list (resulting in long-term authentication requiring three transactions for stunbis clients whose users who are still on MD5). Despite the triple transaction, I’m inclined to recommen d the latter. > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > - -- 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 v2 iQIcBAEBCAAGBQJVrbihAAoJECnERZXWan7EQKAQAIgev+NxLrtirdZ78jkQQeO/ ZB/rH52STyLgbh0Y90qHW6EuMF18FCeMrMGgEyd3OgYsktSFaUpZXYnh9b/lP+FR BaAEnx0MKyxnmqnO23ORw6nyQYcwgaIINtEupKk1x7fA6lfwswsJ47g4CkoBc2pC cVQpMYwoSw34kUratdvyWCgwF+8ejHnZlhFo8vjcpblBJDsB0C5HGEJ9/0edPQGO 3AodNNqzf4TvOJSqCx0E24/tDouXshCaoKCqyIBV2YKxKvs4JWbtJA7b+8KrSlHY 7gk2n0+Ydp15ydn8PDD1x7Idq+f05e7mTbBwVreMzcqBQ0QHacKKhVGLd4s9BYnE 75lJvXwqZT2DRkN9lo0oWe2sbLUdlbM3cz6dpEz2oOvdugOMPn1ojoAFjLskkpVp DorQ4xWqqDE+0HamhPqA1//GJL2ac55qQFPzcCxP/axtPk4TqJ/wrZxbXriPNru3 O6zpC0h3ddLH78bfb+V1KTC8HyNDobng+Ekx4oFQQF0dSCEI1QjPTXepVX5LemFg /RCe8XArf5Mc4IPMbsciPOdR+yagL7soTV7SRNtXPuL8/q29i1aYZrayHVVqzpJ5 PntPJ1Q/1KtSPs5vnHa8T9vgW4wVGLWc8j0NCdxTe9gRYjvDZfe5Q90xKGJiR5tP 2EqsmhctJN4gqf9TV32Q =983K -----END PGP SIGNATURE----- From nobody Tue Jul 21 04:00:29 2015 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 970581A003A; Tue, 21 Jul 2015 04:00:23 -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 9JS-NK-zWh3u; Tue, 21 Jul 2015 04:00:21 -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 56A5F1A001A; Tue, 21 Jul 2015 04:00:20 -0700 (PDT) Received: from [IPv6:2001:df8:ffff:6:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:ffff:6:ca0a:a9ff:fe2e:a4f6]) (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 ED56C204FA; Tue, 21 Jul 2015 13:00:18 +0200 (CEST) Message-ID: <55AE2641.60308@acm.org> Date: Tue, 21 Jul 2015 13:00:17 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: "tram@ietf.org" , "mmusic@ietf.org" , DISPATCH list Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] Discussions about an ICE WG 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, 21 Jul 2015 11:00:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 There will be a short discussion about creating a new WG for ICE during the DISPATCH session Wednesday morning. There is also time scheduled for this in the MMUSIC session on Friday. - -- 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 v2 iQIcBAEBCAAGBQJVriZAAAoJECnERZXWan7ErAcQAKaXXM5ib5W4qBjPX+pAHSco gjbpPUonT2QZ4cxob6xUwGbovSC+XtO2i8qjrz1/BiuA8RVmHcHQlTT6D0bZAGHF GQRSpFCR+F3Lqvbq2GjF5wKt7LoVB1ywocAMvqo87in6f+xgo8EXHZaPWKaeo2xY 29+PuGzV2rIaifXQLIDuKP55dzu6pBedD+T0XC/AVYx9JOt9u+cK2lvwjdBcz2Lh owG7cxO4a0I3yDeUjWU7qtJWhISsUKXk3iOc9vpKZWL10i/7ySN+K7BriNTNs3Mh i7o7VtnhWpgA6IL/IMCvVL6WrcOfw2t7ZXkAE0pMSqi27LtzHB0zfNko1ADPC01l 2pLdgKxmCnvbhS830Al5yoyFae0XxH3XsZEAT6R2F4qZ4fSJ4XVg4jnSPXxxuttS ZofjV6aiJFaKBPZs8Lb/6GDEXmUKCJULKYkRhyYxBIBzfbNoqGkO8NbZauSgqQo0 ovwHJLFooilU5OtnPJKt3qSxdfnVbqEyYoJDlQs8CkfXBtct8JiU3PNF5sLJ8cSj cO3HOZ2E9AKK6gc4K1w8k5Dt6sfdXVgknKa+iDQPCAmZnu5Z+9rNyAqVYQm91KgC TGT84BNHmHPJLyAjkY0P7GJu4Iedk7cYkkiGyJC+f7thPJpr+crXXbI/A+IkY/6k pCFdtK2+scjMArrN0Lzh =ynES -----END PGP SIGNATURE----- From nobody Tue Jul 21 05:01:30 2015 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 1879C1A0242; Tue, 21 Jul 2015 05:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpmAWcsJ9E4w; Tue, 21 Jul 2015 05:01:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069201A01AE; Tue, 21 Jul 2015 05:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6850; q=dns/txt; s=iport; t=1437480084; x=1438689684; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8GbEhxUCwRhU6ZjAzT64lJAsBmGXk1fkNUs0hz20bGc=; b=FhFscnbw8TOqOi0USXKC3Fyi22ZgRFYICkNifbyQFMNbae/sOXCWQw5W QjDxMTe/O80hswtziPEBNOy4jCpus0Ol5EScWOLgDhi7xLf50q2CpQWHY 1gQfuDvE6v4/3Ejd9bkwTAT2+QQ/uTa0MUKJUsEBu/zTQu3lYuJITW+MW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CEBQDVM65V/40NJK1cgxNUaQaDHLhCKgmBawEJhTdKAhyBHDgUAQEBAQEBAYEKhCQBAQQBAQEgSwsQAgEIBDsDAgICJQsUEQIEDgWILg2zNJZXAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tMgj6BZREBTQQHCYJfL4EUBZRTAYR0hzWCCZcFERVjgSkdgVNvAYEMOoEEAQEB X-IronPort-AV: E=Sophos; i="5.15,515,1432598400"; d="scan'208,217"; a="11669062" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jul 2015 12:01:23 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6LC1MR0024464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 12:01:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 07:01:22 -0500 From: "Pal Martinsen (palmarti)" To: Marc Petit-Huguenin Thread-Topic: [MMUSIC] Discussions about an ICE WG Thread-Index: AQHQw6R14DypyX+mfkW9kPxPQpceeZ3mJniA Date: Tue, 21 Jul 2015 12:01:21 +0000 Message-ID: <3A3AC8DF-38F1-45AC-93F6-5A1DEA59E486@cisco.com> References: <55AE2641.60308@acm.org> In-Reply-To: <55AE2641.60308@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.203.127] Content-Type: multipart/alternative; boundary="_000_3A3AC8DF38F145AC93F65A1DEA59E486ciscocom_" MIME-Version: 1.0 Archived-At: Cc: DISPATCH list , "tram@ietf.org" , "mmusic@ietf.org" Subject: Re: [tram] [MMUSIC] Discussions about an ICE WG 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, 21 Jul 2015 12:01:26 -0000 --_000_3A3AC8DF38F145AC93F65A1DEA59E486ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMjEgSnVsIDIwMTUsIGF0IDEzOjAwLCBNYXJjIFBldGl0LUh1Z3VlbmluIDxwZXRpdGh1Z0Bh Y20ub3JnPG1haWx0bzpwZXRpdGh1Z0BhY20ub3JnPj4gd3JvdGU6DQoNCi0tLS0tQkVHSU4gUEdQ IFNJR05FRCBNRVNTQUdFLS0tLS0NCkhhc2g6IFNIQTI1Ng0KDQpUaGVyZSB3aWxsIGJlIGEgc2hv cnQgZGlzY3Vzc2lvbiBhYm91dCBjcmVhdGluZyBhIG5ldyBXRyBmb3IgSUNFIGR1cmluZyB0aGUg RElTUEFUQ0ggc2Vzc2lvbiBXZWRuZXNkYXkgbW9ybmluZy4NCg0KQSBtYWlsaW5nIGxpc3QgaGF2 ZSBiZWVuIGNyZWF0ZWQgZm9yIHRoaXMgZGlzY3Vzc2lvbiBhdCBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQouLS4NClDDpWwtRXJpaw0KDQoNCg0KVGhlcmUgaXMg YWxzbyB0aW1lIHNjaGVkdWxlZCBmb3IgdGhpcyBpbiB0aGUgTU1VU0lDIHNlc3Npb24gb24gRnJp ZGF5Lg0KDQotIC0tDQpNYXJjIFBldGl0LUh1Z3VlbmluDQpFbWFpbDogbWFyY0BwZXRpdC1odWd1 ZW5pbi5vcmc8bWFpbHRvOm1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPg0KQmxvZzogaHR0cDovL2Js b2cubWFyYy5wZXRpdC1odWd1ZW5pbi5vcmcNClByb2ZpbGU6IGh0dHA6Ly93d3cubGlua2VkaW4u Y29tL2luL3BldGl0aHVnDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9u OiBHbnVQRyB2Mg0KDQppUUljQkFFQkNBQUdCUUpWcmlaQUFBb0pFQ25FUlpYV2FuN0VyQWNRQUth WFhNNWliNVc0cUJqUFgrcEFIU2NvDQpnamJwUFVvblQyUVo0Y3hvYjZ4VXdHYm92U0MrWHRPMmk4 cWpyejEvQml1QThSVm1IY0hRbFRUNkQwYlpBR0hGDQpHUVJTcEZDUitGM0xxdmJxMkdqRjV3S3Q3 TG9WQjF5d29jQU12cW84N2luNmYreGdvOEVYSFphUFdLYWVvMnhZDQoyOStQdUd6VjJySWFpZlhR TElEdUtQNTVkenU2cEJlZEQrVDBYQy9BVll4OUpPdDl1K2NLMmx2d2pkQmN6MkxoDQpvd0c3Y3hP NGEwSTN5RGVValdVN3F0SldoSVNzVUtYazNpT2M5dnBLWldMMTBpLzd5U04rSzdCcmlOVE5zM01o DQppN283VnRuaFdwZ0E2SUwvSU1DdlZMNldyY09mdzJ0N1pYa0FFMHBNU3FpMjdMdHpIQjB6Zk5r bzFBRFBDMDFsDQoycExkZ0t4bUNudmJoUzgzMEFsNXlveUZhZTBYeEgzWHNaRUFUNlIyRjRxWjRm U0o0WFZnNGpuU1BYeHh1dHRTDQpab2ZqVjZhaUpGYUtCUFpzOExiLzZHREVYbVVLQ0pVTEtZa1Jo eVl4QklCemZiTm9xR2tPOE5iWmF1U2dxUW8wDQpvdndISkxGb29pbFU1T3RuUEpLdDNxU3hkZm5W YnFFeVlvSkRsUXM4Q2tmWEJ0Y3Q4SmlVM1BORjVzTEo4Y1NqDQpjTzNIT1oyRTlBS0s2Z2M0SzF3 OGs1RHQ2c2ZkWFZna25LYStpRFFQQ0FtWm51NVorOXJOeUFxVllRbTkxS2dDDQpUR1Q4NEJOSG1I UEpMeUFqa1kwUDdHSnU0SWVkazdjWWtraUd5SkMrZjd0aFBKcHIrY3JYWGJJL0ErSWtZLzZrDQpw Q0ZkdEsyK3Njak1BcnJOMEx6aA0KPXluRVMNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2lj IG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_3A3AC8DF38F145AC93F65A1DEA59E486ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <207CCBF74E511E4F90940F39E1EF0331@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAyMSBKdWwgMjAxNSwgYXQgMTM6 MDAsIE1hcmMgUGV0aXQtSHVndWVuaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRpdGh1Z0BhY20u b3JnIiBjbGFzcz0iIj5wZXRpdGh1Z0BhY20ub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4tLS0tLUJF R0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tPGJyIGNsYXNzPSIiPg0KSGFzaDogU0hBMjU2PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlcmUgd2lsbCBiZSBhIHNob3J0IGRpc2N1c3Np b24gYWJvdXQgY3JlYXRpbmcgYSBuZXcgV0cgZm9yIElDRSBkdXJpbmcgdGhlIERJU1BBVENIIHNl c3Npb24gV2VkbmVzZGF5IG1vcm5pbmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkEgbWFpbGluZyBsaXN0IGhhdmUgYmVlbiBjcmVhdGVk IGZvciB0aGlzIGRpc2N1c3Npb24gYXQmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ljZSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pY2U8L2E+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pi4tLjwvZGl2Pg0KPGRpdj5Qw6Vs LUVyaWs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPlRoZXJlIGlzIGFsc28gdGltZSBzY2hlZHVsZWQgZm9yIHRoaXMg aW4gdGhlIE1NVVNJQyBzZXNzaW9uIG9uIEZyaWRheS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQotIC0tIDxiciBjbGFzcz0iIj4NCk1hcmMgUGV0aXQtSHVndWVuaW48YnIgY2xhc3M9IiI+ DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOm1hcmNAcGV0aXQtaHVndWVuaW4ub3JnIiBjbGFzcz0i Ij5tYXJjQHBldGl0LWh1Z3VlbmluLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpCbG9nOiA8YSBocmVm PSJodHRwOi8vYmxvZy5tYXJjLnBldGl0LWh1Z3VlbmluLm9yZyIgY2xhc3M9IiI+aHR0cDovL2Js b2cubWFyYy5wZXRpdC1odWd1ZW5pbi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KUHJvZmlsZTogPGEg aHJlZj0iaHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vcGV0aXRodWciIGNsYXNzPSIiPmh0dHA6 Ly93d3cubGlua2VkaW4uY29tL2luL3BldGl0aHVnPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPGJyIGNsYXNzPSIiPg0KVmVyc2lv bjogR251UEcgdjI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQppUUljQkFFQkNBQUdCUUpW cmlaQUFBb0pFQ25FUlpYV2FuN0VyQWNRQUthWFhNNWliNVc0cUJqUFgmIzQzO3BBSFNjbzxiciBj bGFzcz0iIj4NCmdqYnBQVW9uVDJRWjRjeG9iNnhVd0dib3ZTQyYjNDM7WHRPMmk4cWpyejEvQml1 QThSVm1IY0hRbFRUNkQwYlpBR0hGPGJyIGNsYXNzPSIiPg0KR1FSU3BGQ1ImIzQzO0YzTHF2YnEy R2pGNXdLdDdMb1ZCMXl3b2NBTXZxbzg3aW42ZiYjNDM7eGdvOEVYSFphUFdLYWVvMnhZPGJyIGNs YXNzPSIiPg0KMjkmIzQzO1B1R3pWMnJJYWlmWFFMSUR1S1A1NWR6dTZwQmVkRCYjNDM7VDBYQy9B Vll4OUpPdDl1JiM0MztjSzJsdndqZEJjejJMaDxiciBjbGFzcz0iIj4NCm93RzdjeE80YTBJM3lE ZVVqV1U3cXRKV2hJU3NVS1hrM2lPYzl2cEtaV0wxMGkvN3lTTiYjNDM7SzdCcmlOVE5zM01oPGJy IGNsYXNzPSIiPg0KaTdvN1Z0bmhXcGdBNklML0lNQ3ZWTDZXcmNPZncydDdaWGtBRTBwTVNxaTI3 THR6SEIwemZOa28xQURQQzAxbDxiciBjbGFzcz0iIj4NCjJwTGRnS3htQ252YmhTODMwQWw1eW95 RmFlMFh4SDNYc1pFQVQ2UjJGNHFaNGZTSjRYVmc0am5TUFh4eHV0dFM8YnIgY2xhc3M9IiI+DQpa b2ZqVjZhaUpGYUtCUFpzOExiLzZHREVYbVVLQ0pVTEtZa1JoeVl4QklCemZiTm9xR2tPOE5iWmF1 U2dxUW8wPGJyIGNsYXNzPSIiPg0Kb3Z3SEpMRm9vaWxVNU90blBKS3QzcVN4ZGZuVmJxRXlZb0pE bFFzOENrZlhCdGN0OEppVTNQTkY1c0xKOGNTajxiciBjbGFzcz0iIj4NCmNPM0hPWjJFOUFLSzZn YzRLMXc4azVEdDZzZmRYVmdrbkthJiM0MztpRFFQQ0FtWm51NVomIzQzOzlyTnlBcVZZUW05MUtn QzxiciBjbGFzcz0iIj4NClRHVDg0Qk5IbUhQSkx5QWprWTBQN0dKdTRJZWRrN2NZa2tpR3lKQyYj NDM7Zjd0aFBKcHImIzQzO2NyWFhiSS9BJiM0MztJa1kvNms8YnIgY2xhc3M9IiI+DQpwQ0ZkdEsy JiM0MztzY2pNQXJyTjBMemg8YnIgY2xhc3M9IiI+DQo9eW5FUzxiciBjbGFzcz0iIj4NCi0tLS0t RU5EIFBHUCBTSUdOQVRVUkUtLS0tLTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0K bW11c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNA aWV0Zi5vcmciIGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3A3AC8DF38F145AC93F65A1DEA59E486ciscocom_-- From nobody Tue Jul 21 06:05:08 2015 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 A9D5B1A1B0E for ; Tue, 21 Jul 2015 06:05:06 -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_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VMEQYfywzL_6 for ; Tue, 21 Jul 2015 06:05:05 -0700 (PDT) Received: from smtp96.iad3a.emailsrvr.com (smtp96.iad3a.emailsrvr.com [173.203.187.96]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66F61A1E0F for ; Tue, 21 Jul 2015 06:05:04 -0700 (PDT) Received: from smtp5.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CECFC805CC; Tue, 21 Jul 2015 09:05:03 -0400 (EDT) Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E1A95805A4; Tue, 21 Jul 2015 09:05:02 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-a276.meeting.ietf.org (dhcp-a276.meeting.ietf.org [31.133.162.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 21 Jul 2015 13:05:03 GMT From: Cullen Jennings Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2015 15:05:01 +0200 To: tram@ietf.org, Adam Roach Message-Id: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [tram] Security use case around 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, 21 Jul 2015 13:05:06 -0000 Let work though the issue with anycast. Imagine the case where the = anycast address happened to belong to Cisco. I realize we would not use = that IP address but I will get to that later. Now imagine some users = happens to be at their friends houses using the friends wireless and = that person does not have anything special configured. When the browser = does the auto discovery, there will be no local routing of the IP = address so Cisco=E2=80=99s turn server will get used. It=E2=80=99s a = little confusing how what credential will be used with the server but it = seems likely that the scheme we end up with will involve things like = giving the turn server an OAuth token along with the Origin where it it = from. The TURN server learns all kinds of things. What IPs are calling each = other, how long the calls last, and probably a fair amount of = correlation if the same certificates are used for multiple calls which = seems likely. I don=E2=80=99t really think too much is leaked by the non = CBR encrypted voice issue but some people do and the server would see = all that. Effectively this added Cisco as an on path attacker to all the = media when previously Cisco was not on the path. So obviously we would not use one of Cisco=E2=80=99s IP for this. But = the more you think about it, the IP we would use is not much better for = many of the attacks we care about it. It certainly realistic that a = country or ISP could use BGP to ensure a fairly wide set of locations = routed that anycast address to a proxy of their choice. I have tested = addresses out of the 192.0.0.0 block to see if equipment routes it and = it=E2=80=99s clear a lot of stuff does.=20 The arguments keeps getting made that when I connect to gogo wifi on a = plane that the AP is a trusted element. That=E2=80=99s insane - of = course I don=E2=80=99t trust it with my info - I=E2=80=99m just using it = and want to reveal to it as little as possible. The argument get mades = =E2=80=9Cbut it owns you because it owns the DNS=E2=80=9D. There are a = variety of things one can do to mitigate that and more work is being = done to close remaining holes. For example configuring a DNS server = instead of the DHCP provided one, or using DTLS to a trusted DNS server, = or DNSCrypt etc. The argument is made that one trusts the DHCP sever = from the gogo AP by using it. Again, I don=E2=80=99t think people are = trusting more than it gave them an IP to use. I would not want to make = my security rely on the domain name returned by the gogo DHCP server. = Now clearly gogo can currently MITM all the TLS but obviously we are = doing our best to stop that from being possible. That=E2=80=99s because = we don=E2=80=99t trust the AP. Yes, gogo does seem how much traffic I = send over my VPN but they can be used without revelling much more than = that. A TURN server sees a lot more metadata than some one that just = sees the VPN traffic. Every advertising company would love to collect a = list all the companies that a given person calls.=20 Of course there are many AP=E2=80=99s that one might trust. For example = if you a enterprise user is in the enterprise and did 802.1x and = authenticated the AP, I=E2=80=99d view that as one that could be = trustable. But that=E2=80=99s a bit different from gogo=E2=80=99s AP. From nobody Tue Jul 21 06:33:07 2015 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 064881B2DA1 for ; Tue, 21 Jul 2015 06:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZUG1JVOsMJu for ; Tue, 21 Jul 2015 06:33:04 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA451B2D8E for ; Tue, 21 Jul 2015 06:33:04 -0700 (PDT) Received: by igvi1 with SMTP id i1so102472955igv.1 for ; Tue, 21 Jul 2015 06:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fTa8oVfBMXxw3MvJFeiF0YCfJqwLFiZjtUf0IoCjA54=; b=M8eAxN89jFCDZwXdTgY1eZouUCx014iBI6ggEyzogIZnLKx7mFvQGy1noFX8xyKdB9 ilYH6GjnWul0bcYwgI2Hnux+hl2JQVxmLWq5KHi9Ilzf32iTd98o0HJXNygYW+wXtvEd WGaySrcoN3KOLb9CySWD5UOk5nbBa9j4a/eWkWXRaom5pCwxjujukgS3XEURAujDNQ3z vq9J9UyjXPYp2dzDFmyN1aHNLNejsylkuKtBG1G95bU5smW12o+8YDqH9gkOTRSTWmlt Nm8TIs21ZxoNq9/2gJeSb7X6Sj6I/xdsLXtztPgJlyLJjO+KC+7VugMMqTb+XCdEvKoR /gKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fTa8oVfBMXxw3MvJFeiF0YCfJqwLFiZjtUf0IoCjA54=; b=Phf6UMnWm1zqGCulD30RLzGvFgr0vd48fcNvx91/VdtH4seeZ+gr/G9DP0WDOxka9q KgoV2djwX08BiMyw4KET47qeMkDwr7v6CDIUMABCH5lEfYGlifVcWjdCW99Ih/TAPRq1 9DJhTboCITgALBc+pFx7I05OWUaU6a64Q2q2+C+ciOmA3yw2jJT7YB6RWyw8Ia6wdAFV PBHViaXw/LLdlEjP0sqyefO52pqDGIAb+QWkCypBnkfTtqrF9zthiVUYEgrBKH4f3Fg0 MDcIWIh6DdtJFov0kuTtYWh7/tAaguFYA/KhMTs68zZyLhtykr7V98f6e9LYxBukunBT q9xg== X-Gm-Message-State: ALoCoQkMd/GbgeiMbpvK2folSAE/StFQQpSzRzyneNhHkUD0m1cL0lfuYj6EVBKQrHHANEjte2Ig X-Received: by 10.50.134.226 with SMTP id pn2mr24686118igb.21.1437485583841; Tue, 21 Jul 2015 06:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.234 with HTTP; Tue, 21 Jul 2015 06:32:44 -0700 (PDT) In-Reply-To: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> References: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> From: Justin Uberti Date: Tue, 21 Jul 2015 06:32:44 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7b2e148d987527051b62b127 Archived-At: Cc: Adam Roach , "tram@ietf.org" Subject: Re: [tram] Security use case around 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, 21 Jul 2015 13:33:06 -0000 --047d7b2e148d987527051b62b127 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 21, 2015 at 6:05 AM, Cullen Jennings wrote: > > Let work though the issue with anycast. Imagine the case where the anycas= t > address happened to belong to Cisco. I realize we would not use that IP > address but I will get to that later. Now imagine some users happens to = be > at their friends houses using the friends wireless and that person does n= ot > have anything special configured. When the browser does the auto discover= y, > there will be no local routing of the IP address so Cisco=E2=80=99s turn = server > will get used. It=E2=80=99s a little confusing how what credential will b= e used > with the server but it seems likely that the scheme we end up with will > involve things like giving the turn server an OAuth token along with the > Origin where it it from. > > The TURN server learns all kinds of things. What IPs are calling each > other, how long the calls last, and probably a fair amount of correlation > if the same certificates are used for multiple calls which seems likely. = I > don=E2=80=99t really think too much is leaked by the non CBR encrypted vo= ice issue > but some people do and the server would see all that. Effectively this > added Cisco as an on path attacker to all the media when previously Cisco > was not on the path. > Can't the AP collect all this information as well? --047d7b2e148d987527051b62b127 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 21, 2015 at 6:05 AM, Cullen Jennings <= fluffy@iii.ca> wrote:

Let work though the issue with anycast. Imagine the case where the anycast = address happened to belong to Cisco. I realize we would not use that IP add= ress but I will get to that later.=C2=A0 Now imagine some users happens to = be at their friends houses using the friends wireless and that person does = not have anything special configured. When the browser does the auto discov= ery, there will be no local routing of the IP address so Cisco=E2=80=99s tu= rn server will get used. It=E2=80=99s a little confusing how what credentia= l will be used with the server but it seems likely that the scheme we end u= p with will involve things like giving the turn server an OAuth token along= with the Origin where it it from.

The TURN server learns all kinds of things. What IPs are calling each other= , how long the calls last, and probably a fair amount of correlation if the= same certificates are used for multiple calls which seems likely. I don=E2= =80=99t really think too much is leaked by the non CBR encrypted voice issu= e but some people do and the server would see all that. Effectively this ad= ded Cisco as an on path attacker to all the media when previously Cisco was= not on the path.

Can't the AP coll= ect all this information as well?=C2=A0
--047d7b2e148d987527051b62b127-- From nobody Tue Jul 21 06:56:36 2015 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 D4C371A87E1 for ; Tue, 21 Jul 2015 06:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkvLIIxL8azO for ; Tue, 21 Jul 2015 06:56:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A491A888E for ; Tue, 21 Jul 2015 06:56:20 -0700 (PDT) Received: from dhcp-88a4.meeting.ietf.org (dhcp-88a4.meeting.ietf.org [31.133.136.164]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6LDu89n045748 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 21 Jul 2015 08:56:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <55AE4F78.6010408@nostrum.com> Date: Tue, 21 Jul 2015 15:56:08 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Justin Uberti , Cullen Jennings References: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070500040705090209000307" Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Security use case around 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, 21 Jul 2015 13:56:26 -0000 This is a multi-part message in MIME format. --------------070500040705090209000307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/21/15 15:32, Justin Uberti wrote: > > > On Tue, Jul 21, 2015 at 6:05 AM, Cullen Jennings > wrote: > > > Let work though the issue with anycast. Imagine the case where the > anycast address happened to belong to Cisco. I realize we would > not use that IP address but I will get to that later. Now imagine > some users happens to be at their friends houses using the friends > wireless and that person does not have anything special > configured. When the browser does the auto discovery, there will > be no local routing of the IP address so Cisco’s turn server will > get used. It’s a little confusing how what credential will be used > with the server but it seems likely that the scheme we end up with > will involve things like giving the turn server an OAuth token > along with the Origin where it it from. > > The TURN server learns all kinds of things. What IPs are calling > each other, how long the calls last, and probably a fair amount of > correlation if the same certificates are used for multiple calls > which seems likely. I don’t really think too much is leaked by the > non CBR encrypted voice issue but some people do and the server > would see all that. Effectively this added Cisco as an on path > attacker to all the media when previously Cisco was not on the path. > > > Can't the AP collect all this information as well? Right -- I made exactly this point at the microphone. The exception is the "VPN as default route" case; but, for that situation, you're routing to whatever your VPN has set up for the anycast address, not for where the local network sends it, so it's no worse in that case either. >> It certainly realistic that a country or ISP could use BGP to ensure >> a fairly wide set of locations routed that anycast address to a proxy >> of their choice. Cullen -- your assertion here seems to be predicated on anycast addresses being easier to hijack than other IP addresses. This isn't self-evident [1]. Can you explain why you think this is true? /a ____ [1] And, in fact, I think I can make an argument that they're actually harder to hijack in many cases. --------------070500040705090209000307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/21/15 15:32, Justin Uberti wrote:


On Tue, Jul 21, 2015 at 6:05 AM, Cullen Jennings <fluffy@iii.ca> wrote:

Let work though the issue with anycast. Imagine the case where the anycast address happened to belong to Cisco. I realize we would not use that IP address but I will get to that later.  Now imagine some users happens to be at their friends houses using the friends wireless and that person does not have anything special configured. When the browser does the auto discovery, there will be no local routing of the IP address so Cisco’s turn server will get used. It’s a little confusing how what credential will be used with the server but it seems likely that the scheme we end up with will involve things like giving the turn server an OAuth token along with the Origin where it it from.

The TURN server learns all kinds of things. What IPs are calling each other, how long the calls last, and probably a fair amount of correlation if the same certificates are used for multiple calls which seems likely. I don’t really think too much is leaked by the non CBR encrypted voice issue but some people do and the server would see all that. Effectively this added Cisco as an on path attacker to all the media when previously Cisco was not on the path.

Can't the AP collect all this information as well? 

Right -- I made exactly this point at the microphone.

The exception is the "VPN as default route" case; but, for that situation, you're routing to whatever your VPN has set up for the anycast address, not for where the local network sends it, so it's no worse in that case either.

It certainly realistic that a country or ISP could use BGP to ensure a fairly wide set of locations routed that anycast address to a proxy of their choice.

Cullen -- your assertion here seems to be predicated on anycast addresses being easier to hijack than other IP addresses. This isn't self-evident [1]. Can you explain why you think this is true?

/a

____
[1] And, in fact, I think I can make an argument that they're actually harder to hijack in many cases.
--------------070500040705090209000307-- From nobody Tue Jul 21 13:44:48 2015 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 07A541B304B for ; Tue, 21 Jul 2015 13:44:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wUBYwxwem7Kt for ; Tue, 21 Jul 2015 13:44:45 -0700 (PDT) Received: from smtp64.ord1c.emailsrvr.com (smtp64.ord1c.emailsrvr.com [108.166.43.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5141B304A for ; Tue, 21 Jul 2015 13:44:44 -0700 (PDT) Received: from smtp25.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp25.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 548CE1803CE; Tue, 21 Jul 2015 16:44:44 -0400 (EDT) Received: by smtp25.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7D64618027D; Tue, 21 Jul 2015 16:44:43 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.50.152.236] ([UNAVAILABLE]. [62.168.40.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 21 Jul 2015 20:44:44 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: Cullen Jennings In-Reply-To: <55AE4F78.6010408@nostrum.com> Date: Tue, 21 Jul 2015 22:44:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <61D0BF3A-7664-44D6-A596-A09C8A71E5A9@iii.ca> References: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> <55AE4F78.6010408@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] Security use case around 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, 21 Jul 2015 20:44:47 -0000 > On Jul 21, 2015, at 3:56 PM, Adam Roach wrote: >=20 > On 7/21/15 15:32, Justin Uberti wrote: >>=20 >>=20 >> On Tue, Jul 21, 2015 at 6:05 AM, Cullen Jennings = wrote: >>=20 >> Let work though the issue with anycast. Imagine the case where the = anycast address happened to belong to Cisco. I realize we would not use = that IP address but I will get to that later. Now imagine some users = happens to be at their friends houses using the friends wireless and = that person does not have anything special configured. When the browser = does the auto discovery, there will be no local routing of the IP = address so Cisco=E2=80=99s turn server will get used. It=E2=80=99s a = little confusing how what credential will be used with the server but it = seems likely that the scheme we end up with will involve things like = giving the turn server an OAuth token along with the Origin where it it = from. >>=20 >> The TURN server learns all kinds of things. What IPs are calling each = other, how long the calls last, and probably a fair amount of = correlation if the same certificates are used for multiple calls which = seems likely. I don=E2=80=99t really think too much is leaked by the non = CBR encrypted voice issue but some people do and the server would see = all that. Effectively this added Cisco as an on path attacker to all the = media when previously Cisco was not on the path. >>=20 >> Can't the AP collect all this information as well?=20 >=20 > Right -- I made exactly this point at the microphone. As I said at the mic, yes of course. But now anyone who is on the = routing path of the anycast address can also collect it. Before they = could not. What I said is allows a broader set of people that used to be = off path attackers to become on path attackers.=20 From nobody Tue Jul 21 23:37:21 2015 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 3C7421ACDB6 for ; Tue, 21 Jul 2015 23:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 3lQqMVcx04pD for ; Tue, 21 Jul 2015 23:37:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 068311ACDCF for ; Tue, 21 Jul 2015 23:37:18 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BC5A84D5A3; Wed, 22 Jul 2015 06:37:58 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A5DF04D5A2; Wed, 22 Jul 2015 06:37:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437547078; bh=xG8H6q8gaeDmikN8nBljf/00Sw0rqn7T/Lk+w5zgo1M=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=sylAgzgZutGwJgiGzOBDRbgjL/If6JRxi+WKsXGVF8+NpmY9SKCOI/YLmzIlwF73i nDh1RCavKzrEeJqmqffoQAS5yK9vBojZdhQauV6nKDGl1PtytoHDUa0qmmeSoTVWt4 EwdInJ9BJifW48QFVh34GHfF8dSEgza0rPD4JozU= Received: from [172.28.112.205] (bowill.kendall.corp.akamai.com [172.28.112.205]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id F196080571; Wed, 22 Jul 2015 06:37:17 +0000 (GMT) Message-ID: <55AF3A1D.7060105@akamai.com> Date: Wed, 22 Jul 2015 02:37:17 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Cullen Jennings , Adam Roach References: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> <55AE4F78.6010408@nostrum.com> <61D0BF3A-7664-44D6-A596-A09C8A71E5A9@iii.ca> In-Reply-To: <61D0BF3A-7664-44D6-A596-A09C8A71E5A9@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] Security use case around 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, 22 Jul 2015 06:37:21 -0000 Let's return to Adam's other question ... What about anycast addresses makes this worse? There's nothing special about anycast addresses. Any address can be hijacked via BGP just as easily as any other. As long as you have buy-in from the various routers along the path to allow the hijack, which is required for anycast too, the packets will follow the path that you set up. Am I missing some special characteristic of an anycast address that makes it different from any other address and somehow more susceptible to hijack? I also have a separate question which is why should I care about how easy it is for gogo to hijack the routing for whatever relay I might decide to use? If I use (D)TLS, I should be able to detect when they try to become the relay and I should be able to protect my metadata from untrusted third parties in the path between me and my trusted relay (including an untrusted border relay if I use return to get to the trusted relay). --Brandon On 07/21/2015 04:44 PM, Cullen Jennings wrote: > >> On Jul 21, 2015, at 3:56 PM, Adam Roach wrote: >> >> On 7/21/15 15:32, Justin Uberti wrote: >>> >>> >>> On Tue, Jul 21, 2015 at 6:05 AM, Cullen Jennings wrote: >>> >>> Let work though the issue with anycast. Imagine the case where the anycast address happened to belong to Cisco. I realize we would not use that IP address but I will get to that later. Now imagine some users happens to be at their friends houses using the friends wireless and that person does not have anything special configured. When the browser does the auto discovery, there will be no local routing of the IP address so Cisco’s turn server will get used. It’s a little confusing how what credential will be used with the server but it seems likely that the scheme we end up with will involve things like giving the turn server an OAuth token along with the Origin where it it from. >>> >>> The TURN server learns all kinds of things. What IPs are calling each other, how long the calls last, and probably a fair amount of correlation if the same certificates are used for multiple calls which seems likely. I don’t really think too much is leaked by the non CBR encrypted voice issue but some people do and the server would see all that. Effectively this added Cisco as an on path attacker to all the media when previously Cisco was not on the path. >>> >>> Can't the AP collect all this information as well? >> >> Right -- I made exactly this point at the microphone. > > As I said at the mic, yes of course. But now anyone who is on the routing path of the anycast address can also collect it. Before they could not. What I said is allows a broader set of people that used to be off path attackers to become on path attackers. > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Wed Jul 22 01:08:03 2015 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 D99CE1B3080 for ; Wed, 22 Jul 2015 01:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2kV6iTfwyW1 for ; Wed, 22 Jul 2015 01:08:00 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2051B304F for ; Wed, 22 Jul 2015 01:08:00 -0700 (PDT) Received: by ykdu72 with SMTP id u72so186501794ykd.2 for ; Wed, 22 Jul 2015 01:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=G1VNW1Yqn70HcC+FNGoFGI1geN7wbJZ9Vl+py0mPlLM=; b=nHD4pSHSj+Va9/8znR+e/py09HMFw46+aHVwZqIYchSfGL8uO4+SjN2aV1KewtBFSY y45/mKNmbRqMcOt24kJn48MECMRK/EjlJx2G+GkiHL2vGBbjNcQ7c1Uzn9QObN1628dK y0zcYrfZ4rFrNvqlbyd6haLTUgLB0Bc7Qyx0fmLNBGd3E2GWlmcYd+UJTRCMcLALxOB5 woZ/RvZdP+f1YmLmnZBGLJRgNV6bNNG7J612hP/pxE6bqr2LGJxGe3+6dueQoHGmeNVr iHZ21f8u9ulkoebXe9dsRSZCTcN5sobrmmQyvejk2ewteTu1D0JH/4WKC4qiheKRfIsU 62TA== MIME-Version: 1.0 X-Received: by 10.13.233.133 with SMTP id s127mr1182441ywe.154.1437552480139; Wed, 22 Jul 2015 01:08:00 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 01:08:00 -0700 (PDT) In-Reply-To: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> References: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> Date: Wed, 22 Jul 2015 01:08:00 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Adam Roach , "tram@ietf.org" Subject: Re: [tram] Security use case around 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, 22 Jul 2015 08:08:02 -0000 On 21 July 2015 at 06:05, Cullen Jennings wrote: > the AP is a trusted element. That=E2=80=99s insane +1 From nobody Wed Jul 22 01:49:51 2015 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 3745A1ACE39 for ; Wed, 22 Jul 2015 01:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 6N1YbWAu1TZ4 for ; Wed, 22 Jul 2015 01:49:48 -0700 (PDT) Received: from nm34-vm1.bullet.mail.ne1.yahoo.com (nm34-vm1.bullet.mail.ne1.yahoo.com [98.138.229.81]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED991A8A3C for ; Wed, 22 Jul 2015 01:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1437554987; bh=GieyEpuh/Ybq6NQJ8h/+9mpEKN1gDut+MJg9HIqZ4H8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=ZBccTr61wgp3U7MaXwc9jp16xRuDdLAQK88suIdU/b4rzjFMjbSdU+OfQrgKzDnjq0G/oyjtxSE1HdN2gy0DWrrBOIaEWGlY5QBdQMtQZefpUEO4o14zSiNfMF3WWu+FT03k3trD6efJEKtkVechmaAgkZFcdY7FRTs70FbA8Ly/zLEb+L6ypIpMhsYiyz2YyjT42cUDT5R78Q+AG34LYYc+/jKhTObHOkjRWcCwsFAMvp9k2Cq1t3DS4eBrYJbBKVtTnA5EGTiOat7EUGzQKrtQ16r+BmNx3kj5/l7QYBpdNlYtJAOusaTeaBvfqulcjIayQ7emuwRCWNYxnIqsmg== Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jul 2015 08:49:47 -0000 Received: from [98.138.100.114] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jul 2015 08:46:47 -0000 Received: from [98.138.226.125] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jul 2015 08:46:47 -0000 Received: from [127.0.0.1] by smtp204.mail.ne1.yahoo.com with NNFMP; 22 Jul 2015 08:46:47 -0000 X-Yahoo-Newman-Id: 180937.96033.bm@smtp204.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: um9TS30VM1kJ30pzpc0arL5Ax_ruqK_Yc3J0L0Oun8FrGuH O_6ImgbRFVLlhqDlEmNUSUfCJ3r8qEBlpvRus2MfvC8FbTwDnvoZuAX6rTbP fQHLQJ76pdV9vB0VLByJDqdBm63rpCrxMtiug43v6QoM3OFVRYIHksC3Ecw3 _qGxIP23pPDQW6SIbrDCVdUVYXphS_YKOxglT4HwOK0.Fdd0exmdRdCydmwu NWGsZFskP_G0sJhcAc9UD2MZc9hUQp2yoU6begAL88SSnBT4j8b6_2j9JkIU N8EXok245AlqSAdXP.S3My5BtHZvFQjh9UWqwRgJOYNJgzrSeDWfhhUL1zN8 JMCPdkHzaCij5_Y3ncspS3LRXM9A2_qqPjG7n.mWVawHEyX5GQB2Fa98Kyu1 mJ7DRCU4Q2HbLzfAOfFjAvhAzU9098.kzlQ7V6U5YgCfJg.c1WcwhX4WgLlU mOzbLVQTueaalo4hrgdykktbPLVMRxlf454WgCWIcx_DEqitN_Yr.IW1wmas makVR6yQsIl0CbHOetWzRsxiXkAjRi.mJf0QDWx0- X-Yahoo-SMTP: zG6hRFWswBBEnv0PXR_VlKFE Message-ID: <55AF5876.6090907@nostrum.com> Date: Wed, 22 Jul 2015 10:46:46 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Cullen Jennings References: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> <55AE4F78.6010408@nostrum.com> <61D0BF3A-7664-44D6-A596-A09C8A71E5A9@iii.ca> In-Reply-To: <61D0BF3A-7664-44D6-A596-A09C8A71E5A9@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] Security use case around 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, 22 Jul 2015 08:49:50 -0000 On 7/21/15 22:44, Cullen Jennings wrote: > [A]nyone who is on the routing path of the anycast address can also collect it. Before they could not. What I said is allows a broader set of people that used to be off path attackers to become on path attackers. For any of your objections to be a coherent argument against using anycast, they would have to be false if you replace "anycast" with "non-anycast." This one fails that test. /a From nobody Wed Jul 22 01:56:49 2015 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 5CAE91ACF19 for ; Wed, 22 Jul 2015 01:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 grn3pJMqxwEN for ; Wed, 22 Jul 2015 01:56:45 -0700 (PDT) Received: from nm39-vm8.bullet.mail.ne1.yahoo.com (nm39-vm8.bullet.mail.ne1.yahoo.com [98.138.229.168]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407471ACF09 for ; Wed, 22 Jul 2015 01:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1437555404; bh=1g/J0jk6SSB0FlEWfNdNRieHJgXRST8aKfLEY/FMF4A=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=cc1aMZNYlaxvFDE+JJiBth7o/Sw7FN8wpiTqLMuW1OBNFEEb9/ijPOwd9Pno6tWuSL89/SF0xnxuhrhgZ1z0IYXoL6DJWjvBufC89TGZtZn3smM+PAWF2z8T/fNHrhIfZ8pVQK8+FdS45riGhG5rx8Xj7QwhaQC+d/R+Hnxtyz7d3RID5ksNvrZEV7sQZoo+8UwWvcVV8z8MSQic4+13xFEAgblUeTPrzso8mZs3QHkBbjssnpk4Y6O4hpd2HTab31/QrPWcPM9vBjxsDewMqre5ea5wjf49m4fZL1vNQoPm/Y2gCX357ZKBJKRve2pwYRNVAbrxK7P9JjJ8Cwl4iQ== Received: from [127.0.0.1] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jul 2015 08:56:44 -0000 Received: from [98.138.100.115] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jul 2015 08:53:44 -0000 Received: from [98.138.226.56] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jul 2015 08:53:44 -0000 Received: from [127.0.0.1] by smtp207.mail.ne1.yahoo.com with NNFMP; 22 Jul 2015 08:53:44 -0000 X-Yahoo-Newman-Id: 473390.59465.bm@smtp207.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: QymK4VQVM1nqIO4.q0aaQi2XMezsXogxCyNg7kTerp40AQp X8fMvbLYnGxvFL4CaWkgXpDbxbyvclrY3Nm2U9cAr17Ce7mEFDmj3A4LyThX yQSlyD_M_Bb5pnMZC5JswJ0GQhuuxn4wG0Ap2cMhgCLJoRd2Tw0hmfp1qzKT Lg1ZhxHP3Vi9P07nTTCHVRE6oVaj73uCHbKGsR0F8h1bjpVgrD6iUeVBY.Ws QqImLptwpCfKg3Ffjne768352wFDU_9r4o3xfkPluP10xg_fBTccfMiGivrp vIqXGf3h.Ch0L3jEIgg019ioU.ObK1gKZHod7pQIY4wkUdAsRx4wuBaIdGuE c1L_QVlddA.Q_7GcFJoBkPwZoaNJQdNqKmQ7CA7E.TJ6bG7v3iR7F03Dz9CH BK3aBcWtOh84.vz3NYzHJgM5ejpY1nBELP4M8uTl8u507bB_XeLFMI37W7Mt xWbE4UYT77PSmxAaRlr0reOhAWPNdgy7cQDbVQUDS1mQeJar_ynR.mSe7t6k 8wlYme7k1yqRqOU6KkJL11NJVV9g2cEARw7Wzuzl5UbDnQRF6TGw- X-Yahoo-SMTP: zG6hRFWswBBEnv0PXR_VlKFE Message-ID: <55AF5A17.4070308@nostrum.com> Date: Wed, 22 Jul 2015 10:53:43 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Martin Thomson , Cullen Jennings References: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020707020208070804040702" Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Security use case around 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, 22 Jul 2015 08:56:48 -0000 This is a multi-part message in MIME format. --------------020707020208070804040702 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/22/15 10:08, Martin Thomson wrote: > On 21 July 2015 at 06:05, Cullen Jennings wrote: >> the AP is a trusted element. That’s insane > +1 Sure. Motherhood and apple pie. I'm not arguing from the perspective that the AP is supposed to be trusted. My argument is that the AP has access to source and destination information as well as the payloads, by virtue of where it is in the network. You can't argue that giving it access to these three pieces of information is somehow a risk, because /it already has access to them/. If it's going to act maliciously, then anything you can do maliciously with this information is already possible. The crux of Cullen's argument regarding APs is that they'll somehow allow access to this information if and only if we use anycast for discovery. That simply doesn't follow, since /they already have that access/. /a --------------020707020208070804040702 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/22/15 10:08, Martin Thomson wrote:
On 21 July 2015 at 06:05, Cullen Jennings <fluffy@iii.ca> wrote:

the AP is a trusted element. That’s insane

+1

Sure. Motherhood and apple pie. I'm not arguing from the perspective that the AP is supposed to be trusted.

My argument is that the AP has access to source and destination information as well as the payloads, by virtue of where it is in the network. You can't argue that giving it access to these three pieces of information is somehow a risk, because it already has access to them. If it's going to act maliciously, then anything you can do maliciously with this information is already possible.

The crux of Cullen's argument regarding APs is that they'll somehow allow access to this information if and only if we use anycast for discovery. That simply doesn't follow, since they already have that access.

/a
--------------020707020208070804040702-- From nobody Wed Jul 22 01:56:59 2015 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 A29A91ACEF4 for ; Wed, 22 Jul 2015 01:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.062 X-Spam-Level: ** X-Spam-Status: No, score=2.062 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, RDNS_NONE=0.793, 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 BVvlCGyjY5NI for ; Wed, 22 Jul 2015 01:56:52 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E09A01ACF18 for ; Wed, 22 Jul 2015 01:56:47 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B47914D5AA; Wed, 22 Jul 2015 08:57:27 +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 9DD684D097; Wed, 22 Jul 2015 08:57:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437555447; bh=r85mPauvDDcIvZSONtcXICtTEuu5Pca623MWXWGv5Zg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=VhZ1Cxv9LD5RhDUHtVFCDIeO5HXiPuib0tcgOArj0yyS0uubo5oZP41GVHe9bhWlh NgoIwxM52yctzn7TCEXT4zTdpu7ZjmAeBsGwNTv8lHT7777fH5tMw5N4dnII7iX7jq vnK3U4K3ZHQfIlblIczt952pQ1DN4P5DH6jfiABo= Received: from [172.28.112.205] (bowill.kendall.corp.akamai.com [172.28.112.205]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 5B9E5206C; Wed, 22 Jul 2015 08:56:46 +0000 (GMT) Message-ID: <55AF5ACE.3060100@akamai.com> Date: Wed, 22 Jul 2015 04:56:46 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Cullen Jennings , tram@ietf.org, Adam Roach References: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> In-Reply-To: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Security use case around 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, 22 Jul 2015 08:56:54 -0000 I fully agree that the AP is not to be trusted unless you trust the AP's administrator and use some mechanism to verify that you have connected to the intended AP. No one should trust gogo wifi. That said, I haven't heard anyone make this argument. Maybe it's been made in another context, but I don't think that argument has been made on the tram list nor do I think it was made in the meeting yesterday. What I think was asked for is an explanation of why we should be more concerned about using an untrusted relay than we should be about using an untrusted AP. As soon as the untrusted AP gets into the flow, I can no longer trust that my packets will be delivered to the intended destination. The packets can follow any path that the AP chooses on the way to any destination that the AP chooses. There are no guarantees. And any node along the untrusted path has equal access to the metadata. --Brandon On 07/21/2015 09:05 AM, Cullen Jennings wrote: > The arguments keeps getting made that when I connect to gogo wifi on a plane that the AP is a trusted element. That’s insane - of course I don’t trust it with my info - I’m just using it and want to reveal to it as little as possible. The argument get mades “but it owns you because it owns the DNSâ€. There are a variety of things one can do to mitigate that and more work is being done to close remaining holes. For example configuring a DNS server instead of the DHCP provided one,or using DTLS to a trusted DNS server, or DNSCrypt etc. The argument is made that one trusts the DHCP sever from the gogo AP by using it. Again, I don’t think people are trusting more than it gave them an IP to use. I would not want to make my security rely on the domain name returned by the gogo DHCP server. Now clearly gogo can currently MITM all the TLS but obviously we are doing our best to stop that from being possible. That’s because we don’t trust the AP. Yes, gogo does seem ho w much t raffic I send over my VPN but they can be used without revelling much more than that. A TURN server sees a lot more metadata than some one that just sees the VPN traffic. Every advertising company would love to collect a list all the companies that a given person calls. > > Of course there are many AP’s that one might trust. For example if you a enterprise user is in the enterprise and did 802.1x and authenticated the AP, I’d view that as one that could be trustable. But that’s a bit different from gogo’s AP. -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Wed Jul 22 09:38:09 2015 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 405A31B2AA2 for ; Wed, 22 Jul 2015 09:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 prbiWguroTzQ for ; Wed, 22 Jul 2015 09:38:05 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 217F81B2AC6 for ; Wed, 22 Jul 2015 09:38:04 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUe31q01e2NEPrz01Ue4Rn; Wed, 22 Jul 2015 18:38:04 +0200 Date: Wed, 22 Jul 2015 18:38:05 +0200 (CEST) From: Meetecho Team To: tram@ietf.org Message-ID: <1044375927.5.1437583085549.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4_1612687302.1437583085547" Archived-At: Subject: [tram] Meetecho recordings of TRAM WG session 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, 22 Jul 2015 16:38:06 -0000 ------=_Part_4_1612687302.1437583085547 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the TRAM WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#TRAM In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_4_1612687302.1437583085547-- From nobody Wed Jul 22 09:55:33 2015 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 55DCA1B2AF8 for ; Wed, 22 Jul 2015 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.38 X-Spam-Level: * X-Spam-Status: No, score=1.38 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2ym-vbKPJUf for ; Wed, 22 Jul 2015 09:55:20 -0700 (PDT) Received: from smtpdg228.aruba.it (smtpdg228.aruba.it [62.149.158.228]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9CD1B2B7B for ; Wed, 22 Jul 2015 09:55:12 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd04.ad.aruba.it with bizsmtp id vUuk1q00X2NEPrz01Uul7x; Wed, 22 Jul 2015 18:54:45 +0200 Date: Wed, 22 Jul 2015 18:54:46 +0200 (CEST) From: Meetecho Team To: tram@ietf.org Message-ID: <637716982.3.1437584086474.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2_110945054.1437584086471" Archived-At: Subject: [tram] Meetecho recordings of TRAM 2nd WG session 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, 22 Jul 2015 16:55:21 -0000 ------=_Part_2_110945054.1437584086471 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the TRAM 2nd WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#TRAM_II In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_2_110945054.1437584086471-- From nobody Mon Jul 27 02:27:40 2015 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 154671B2A13 for ; Mon, 27 Jul 2015 02:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.4 X-Spam-Level: ** X-Spam-Status: No, score=2.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_32=0.6, MSGID_MULTIPLE_AT=1] 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 JNIqeAeW50KR for ; Mon, 27 Jul 2015 02:27:36 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A94B1B29D4 for ; Mon, 27 Jul 2015 02:27:34 -0700 (PDT) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201507271127320621; Mon, 27 Jul 2015 11:27:32 +0200 From: "Karl Stahl" To: "'Brandon Williams'" , "'Cullen Jennings'" , , "'Adam Roach'" References: <26787439-02D3-4287-BAA5-A81D973CB54A@iii.ca> <55AF5ACE.3060100@akamai.com> In-Reply-To: <55AF5ACE.3060100@akamai.com> Date: Mon, 27 Jul 2015 11:27:31 +0200 Message-ID: <038f01d0c84e$7702f070$6508d150$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDEXGHDlrhdiBWNSJCcXA9ykQwHKgD3rMqQ Content-Language: sv Archived-At: Cc: "'Prashanth Patil \(praspati\)'" , 'Benjamin Schwartz' , "'Tirumaleswar Reddy \(tireddy\)'" Subject: Re: [tram] Security use case around 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, 27 Jul 2015 09:27:39 -0000 I read this thread and wonder why the anycast method of = draft-ietf-tram-turn-server-discovery-04.txt is discussed in a use case = around a wrongly configured wrongly advertised "Cisco turn server". 1)=20 Under 9. Security Considerations, 9.3 Anycast in the discovery draft, it = correctly spells out that the anycast route to the server only should be = available to inside (local, LAN side) of the default gateway (that a = network provided turn server parallels to get a good path for real-time = traffic) So at "his friends WiFi AP", there should not even be a route to that = Cisco turn server. 2) Further > "It=E2=80=99s a little confusing how what credential will be used with = the server" It is indeed, and there seem to be a misunderstanding of why we need = discovery of a network provided turn server The very purpose of discovery is to find the turn server offered to = users of the particular network segment that it serves. Simply put, that Cisco turn server should not authenticate Allocate = request from inside users. No credentials needed! If configured to respond to Authenticate requests from outside users, = that Cisco turn server should authenticate outside users, and could then = serve as an application provided TURN server (NOT a network provided = discovered turn server) 3) Further > "The TURN server learns all kinds of things..." So does the default gateway (in case it is not paralleled by a network = provided turn server). Both are provided by the same network admin, so what is the difference? 4) Further > "gogo wifi on a plane that the AP is a trusted element" > " > the AP is a trusted element. That=E2=80=99s insane +1" > "agree that the AP is not to be trusted" This seems to be a matter of terminology: Do we call the one we send our = data to the outside of our network segment (the default gateway) trusted = or not. Let's use "same trust level" instead. A network provided turn server has the same trust level as the default = gateway it is paralleling, so no problem is introduced.=20 This is actually highlighted by = draft-jennings-behave-rtcweb-firewall-00, where the real-time traffic = flow is suggested to be captured in an UDP flow, in the default gateway = path in the firewall. Thus that firewall has the ability to "learns all = kinds of things...", just like a turn server paralleling its default = gateway would have. We give them our real-time traffic with the same = level of trust.=20 5) Very little of this has to do with the anycast method in itself. Is the concern instead that, from network segments NOT having a properly = configured and advertised network provided turn server, the very = discovery process of sending an Allocate request to the anycast address, = may reveal things to the outside or that a far away turn server (not = paralleling any of the default gateways that has to be passed), will be = used? If so, the discovery draft under 9. Security Considerations, 9.3 Anycast = Suggests "...set an IP TTL on their TURN requests that limits how far = they can travel..." Maybe this TTL setting can be guided by a trace route before, so that = TURN requests intended for a network provided turn server never reaches = the public internet. Is there such improvement of the anycast discovery process to be made? We need the discovery and the return drafts to be adopted as soon = possible to get WebRTC going everywhere and with quality!=20 /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Brandon Williams Skickat: den 22 juli 2015 10:57 Till: Cullen Jennings; tram@ietf.org; Adam Roach =C3=84mne: Re: [tram] Security use case around I fully agree that the AP is not to be trusted unless you trust the AP's = administrator and use some mechanism to verify that you have connected = to the intended AP. No one should trust gogo wifi. That said, I haven't heard anyone make this argument. Maybe it's been = made in another context, but I don't think that argument has been made = on the tram list nor do I think it was made in the meeting yesterday. What I think was asked for is an explanation of why we should be more = concerned about using an untrusted relay than we should be about using = an untrusted AP. As soon as the untrusted AP gets into the flow, I can = no longer trust that my packets will be delivered to the intended = destination. The packets can follow any path that the AP chooses on the = way to any destination that the AP chooses. There are no guarantees. And = any node along the untrusted path has equal access to the metadata. --Brandon On 07/21/2015 09:05 AM, Cullen Jennings wrote: > The arguments keeps getting made that when I connect to gogo wifi on a = > plane that the AP is a trusted element. That=E2=80=99s insane - of = course I=20 > don=E2=80=99t trust it with my info - I=E2=80=99m just using it and = want to reveal to=20 > it as little as possible. The argument get mades =E2=80=9Cbut it owns = you=20 > because it owns the DNS=E2=80=9D. There are a variety of things one = can do to=20 > mitigate that and more work is being done to close remaining holes.=20 > For example configuring a DNS server instead of the DHCP provided=20 > one,or using DTLS to a trusted DNS server, or DNSCrypt etc. The=20 > argument is made that one trusts the DHCP sever from the gogo AP by=20 > using it. Again, I don=E2=80=99t think people are trusting more than = it gave=20 > them an IP to use. I would not want to make my security rely on the=20 > domain name returned by the gogo DHCP server. Now clearly gogo can=20 > currently MITM all the TLS but obviously we are doing our best to stop = > that from being possible. That=E2=80=99s because we don=E2=80=99t = trust the AP. Yes,=20 > gogo does seem ho w much t raffic I send over my VPN but they can be used without revelling much = more than that. A TURN server sees a lot more metadata than some one = that just sees the VPN traffic. Every advertising company would love to = collect a list all the companies that a given person calls. > > Of course there are many AP=E2=80=99s that one might trust. For = example if you a enterprise user is in the enterprise and did 802.1x and = authenticated the AP, I=E2=80=99d view that as one that could be = trustable. But that=E2=80=99s a bit different from gogo=E2=80=99s AP. -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Wed Jul 29 08:08:19 2015 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 0D2ED1A8F44 for ; Wed, 29 Jul 2015 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-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 D2X_Z7SZOl0L for ; Wed, 29 Jul 2015 08:08:15 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0694.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::694]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246C11A9086 for ; Wed, 29 Jul 2015 07:53:29 -0700 (PDT) Received: from HE1PR06MB1226.eurprd06.prod.outlook.com (10.162.253.155) by HE1PR06MB1225.eurprd06.prod.outlook.com (10.162.253.154) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 29 Jul 2015 14:53:25 +0000 Received: from HE1PR06MB1226.eurprd06.prod.outlook.com ([10.162.253.155]) by HE1PR06MB1226.eurprd06.prod.outlook.com ([10.162.253.155]) with mapi id 15.01.0225.018; Wed, 29 Jul 2015 14:53:25 +0000 From: =?utf-8?B?U3RlZmFuIE3Dtmhs?= To: "tram@ietf.org" Thread-Topic: TRAM, WebRTC and DHT Thread-Index: AdDKDlKtCHS7hkJQTHiom1sfJHnpSA== Date: Wed, 29 Jul 2015 14:53:24 +0000 Message-ID: Accept-Language: sv-SE, en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2a01:2b0:305a:21:80fa:bc09:f11d:f60f] x-microsoft-exchange-diagnostics: 1; HE1PR06MB1225; 5:vcRXpNiFetIMjOZrfNtIThXJ81/3lPkS20No5S9oh0odgjxsENHbC4bNfrHU9H7TMNCdBGqBClSF2Bah5pvXcyrMZp1DD8cO4ehfhQF/Mc6X8UY1GUgK2d01VVnxAO3ymtxpMFEeww8we9D0FpUX+Q==; 24:xu3Bxp0bCcJvvy5fAIYkQXAj55rDwmKp1VGeTsosoWIdhSKlORrzc1dQa1IGK+Gkw2cbgvCK2wKUCVlTnUF5eY7HQ/1oyCJP0sBlhbhwyYE=; 20:7WI7/jdpRf5qARNc0L2IRDfkBTJSaM8wBcXha1Z+dXNsGwPUfZqkSILKbKyhyBuug2eNvN+f1oMJFFPXoIktLQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR06MB1225; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:HE1PR06MB1225; BCL:0; PCL:0; RULEID:; SRVR:HE1PR06MB1225; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(243025005)(71364002)(19625215002)(19617315012)(19300405004)(15975445007)(16236675004)(19580405001)(229853001)(102836002)(85202003)(85182001)(77096005)(2900100001)(450100001)(62966003)(2351001)(77156002)(92566002)(122556002)(74316001)(40100003)(86362001)(107886002)(87936001)(33656002)(19580395003)(5001960100002)(18206015028)(46102003)(2501003)(189998001)(99936001)(5003600100002)(17760045003)(110136002)(5002640100001)(54356999)(19627595001)(76576001)(50986999)(2656002)(7099028)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR06MB1225; H:HE1PR06MB1226.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_HE1PR06MB1226ED5991A9C1322E9878BDB28C0HE1PR06MB1226eurp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: vergic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 14:53:24.8012 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ba9e495-9ac7-43e7-832e-2969cb00ca4e X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR06MB1225 Archived-At: Subject: [tram] TRAM, WebRTC and DHT X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 15:08:18 -0000 --_004_HE1PR06MB1226ED5991A9C1322E9878BDB28C0HE1PR06MB1226eurp_ Content-Type: multipart/alternative; boundary="_000_HE1PR06MB1226ED5991A9C1322E9878BDB28C0HE1PR06MB1226eurp_" --_000_HE1PR06MB1226ED5991A9C1322E9878BDB28C0HE1PR06MB1226eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhpcyBpcyB0aGUgd3JvbmcgZm9ydW0gZm9yIG15IHF1ZXN0aW9uLCBwbGVhc2UgYWNjZXB0 IG15IGFwb2xvZ2llcyENCg0KSWYgSSB1bmRlcnN0YW5kIHRoaW5ncyBjb3JyZWN0bHksIHRoaXMg SUVURiBncm91cCBpcyB3b3JraW5nIG9uIHRoZSBuZXh0LWdlbiBTVFVOL1RVUk4gcHJvdG9jb2wu IFRoZXJlIGhhcyBhbHNvIGJlZW4gc29tZSB3b3JrIG9uIHVzaW5nIERIVCwgYXQgbGVhc3QgZm9y IFNUVU47IHNlZSwgaS5lLiBodHRwOi8vd3d3LmxhYnJpLmZyL3BlcnNvL3RhZC9kb3dubG9hZC9y YXBwb3J0X1BGRV9waWVycmUucGRmIG9yIGh0dHBzOi8vd3d3Lmdvb2dsZS5zZS91cmw/c2E9dCZy Y3Q9aiZxPSZlc3JjPXMmc291cmNlPXdlYiZjZD0xJmNhZD1yamEmdWFjdD04JnZlZD0wQ0NFUUZq QUFhaFVLRXdpam84T0szX3ZHQWhYR1hDd0tIV1ZhRGNnJnVybD1odHRwJTNBJTJGJTJGbWFpZHNh ZmUubmV0JTJGV2hpdGVwYXBlcnMlMkZwZGYlMkZESFRiYXNlZE5BVFRyYXZlcnNhbC5wZGYmZWk9 MVYyMlZlUGtOY2E1c1FIbHRMWEFEQSZ1c2c9QUZRakNOR2gyRnYxaWc1LWdQRVY2T19rR2VEa2I4 Q1JkQSZzaWcyPVVDclBuUm82NC1URzUtM0RnWWNscVEmYnZtPWJ2Ljk4NzE3NjAxLGQuYkdnDQoN ClNpbmNlIGEgc3Ryb25nIG1vdGl2YXRpb24gZm9yIFRSQU0sIGFzIEkgdW5kZXJzdGFuZCBpdCwg aXMgdGhlIHNoaWZ0IHRvd2FyZHMgdXNpbmcgU1RVTi9UVVJOIGZvciBXZWJSVEMsIGFuZCB0aGUg YmlnIHZhbHVlIGluIFdlYlJUQyBpcyB0aGUgYWxtb3N0IHNlcnZlcmxlc3MgbmF0dXJlIG9mIFdl YlJUQywgSSB3YXMgd29uZGVyaW5nIGlmIHRoaXMgZ3JvdXAgaXMgdGFraW5nIERIVCBpbnRvIGNv bnNpZGVyYXRpb24/IElmIGF0IGxlYXN0IHRoZSBzaWduYWxpbmcgc2VydmVyIGFuZCB0aGUgU1RV TiBzZXJ2ZXIgY291bGQgYmUgc2hpZnRlZCB0byBESFQsIFdlYlJUQyBjb3VsZCBiZWNvbWUgdHJ1 bHkgc2VydmVybGVzcyBmb3IgdGhlIG1ham9yaXR5IG9mIHVzZXJzIHRoYXQgZG8gbm90IHJlcXVp cmUgYSBUVVJOIHNlcnZlciwgYW5kIHRoZXJlYnkgZXh0cmVtZWx5IHJlc2lsaWVudCENCg0KL0tp bmQgcmVnYXJkcywNClN0ZWZhbg0KDQpTdGVmYW4gTcO2aGwgfCBWZXJnaWMgQUINCkNoaWVmIElu ZnJhc3RydWN0dXJlIE9mZmljZXINCg0K4piOKzQ2IDczNS0yMyAxMiA1MA0KQDogc3RlZmFuQHZl cmdpYy5jb208bWFpbHRvOnN0ZWZhbkB2ZXJnaWMuY29tPg0Kdzogd3d3LnZlcmdpYy5jb208aHR0 cDovL3d3dy52ZXJnaWMuY29tLz4NCkZvbGxvdyB1cyBvbiB0d2l0dGVyOiBWZXJnaWM8aHR0cHM6 Ly90d2l0dGVyLmNvbS9WZXJnaWNBQj4NCkZvbGxvdyB1cyBvbiBMaW5rZWRpbjogVmVyZ2ljPGh0 dHA6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvdmVyZ2ljPg0KDQpbY2lkOjAxOUVGN0NGLTND QTQtNEQ2Qy04MDhELUFFMUI4RkRFN0RFN10NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhp cyBlLW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCBjb250YWluIHByb3ByaWV0YXJ5L0Nv bmZpZGVudGlhbCBJbmZvcm1hdGlvbiBwcm90ZWN0ZWQgYnkgbGF3IGFuZCBiZWxvbmdzIHRvIFZl cmdpYyBBQiwgYW5kIGl0cyBhZmZpbGlhdGVzLiBJZiB5b3UgYXJlIG5vdCBhIHJlY2lwaWVudCBp bmRpY2F0ZWQgb3IgaW50ZW5kZWQgaW4gdGhpcyBtZXNzYWdlIChvciByZXNwb25zaWJsZSBmb3Ig ZGVsaXZlcnkgb2YgdGhpcyBtZXNzYWdlIHRvIHN1Y2ggcGVyc29uKSwgb3IgeW91IHRoaW5rIGZv ciBhbnkgcmVhc29uIHRoYXQgdGhpcyBtZXNzYWdlIG1heSBoYXZlIGJlZW4gYWRkcmVzc2VkIHRv IHlvdSBpbiBlcnJvciwgeW91IG1heSBub3QgdXNlIG9yIGNvcHkgb3IgZGVsaXZlciB0aGlzIG1l c3NhZ2UgdG8gYW55b25lIGVsc2UuIEluIHN1Y2ggY2FzZSwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IHJldHVybmluZyB0aGUgZS1tYWlsIGFuZCBkZWxldGUgYWxsIGNv cGllcyBmcm9tIHlvdXIgc3lzdGVtLg0KDQo= --_000_HE1PR06MB1226ED5991A9C1322E9878BDB28C0HE1PR06MB1226eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJ IFN5bWJvbCI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv c2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGlzIGlzIHRoZSB3cm9uZyBm b3J1bSBmb3IgbXkgcXVlc3Rpb24sIHBsZWFzZSBhY2NlcHQgbXkgYXBvbG9naWVzITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SWYgSSB1bmRlcnN0YW5kIHRoaW5ncyBjb3JyZWN0bHksIHRoaXMgSUVURiBn cm91cCBpcyB3b3JraW5nIG9uIHRoZSBuZXh0LWdlbiBTVFVOL1RVUk4gcHJvdG9jb2wuIFRoZXJl IGhhcyBhbHNvIGJlZW4gc29tZSB3b3JrIG9uIHVzaW5nIERIVCwgYXQgbGVhc3QgZm9yIFNUVU47 IHNlZSwgaS5lLg0KPGEgaHJlZj0iaHR0cDovL3d3dy5sYWJyaS5mci9wZXJzby90YWQvZG93bmxv YWQvcmFwcG9ydF9QRkVfcGllcnJlLnBkZiI+aHR0cDovL3d3dy5sYWJyaS5mci9wZXJzby90YWQv ZG93bmxvYWQvcmFwcG9ydF9QRkVfcGllcnJlLnBkZjwvYT4gb3INCjxhIGhyZWY9Imh0dHBzOi8v d3d3Lmdvb2dsZS5zZS91cmw/c2E9dCZhbXA7cmN0PWomYW1wO3E9JmFtcDtlc3JjPXMmYW1wO3Nv dXJjZT13ZWImYW1wO2NkPTEmYW1wO2NhZD1yamEmYW1wO3VhY3Q9OCZhbXA7dmVkPTBDQ0VRRmpB QWFoVUtFd2lqbzhPSzNfdkdBaFhHWEN3S0hXVmFEY2cmYW1wO3VybD1odHRwJTNBJTJGJTJGbWFp ZHNhZmUubmV0JTJGV2hpdGVwYXBlcnMlMkZwZGYlMkZESFRiYXNlZE5BVFRyYXZlcnNhbC5wZGYm YW1wO2VpPTFWMjJWZVBrTmNhNXNRSGx0TFhBREEmYW1wO3VzZz1BRlFqQ05HaDJGdjFpZzUtZ1BF VjZPX2tHZURrYjhDUmRBJmFtcDtzaWcyPVVDclBuUm82NC1URzUtM0RnWWNscVEmYW1wO2J2bT1i di45ODcxNzYwMSxkLmJHZyI+DQpodHRwczovL3d3dy5nb29nbGUuc2UvdXJsP3NhPXQmYW1wO3Jj dD1qJmFtcDtxPSZhbXA7ZXNyYz1zJmFtcDtzb3VyY2U9d2ViJmFtcDtjZD0xJmFtcDtjYWQ9cmph JmFtcDt1YWN0PTgmYW1wO3ZlZD0wQ0NFUUZqQUFhaFVLRXdpam84T0szX3ZHQWhYR1hDd0tIV1Zh RGNnJmFtcDt1cmw9aHR0cCUzQSUyRiUyRm1haWRzYWZlLm5ldCUyRldoaXRlcGFwZXJzJTJGcGRm JTJGREhUYmFzZWROQVRUcmF2ZXJzYWwucGRmJmFtcDtlaT0xVjIyVmVQa05jYTVzUUhsdExYQURB JmFtcDt1c2c9QUZRakNOR2gyRnYxaWc1LWdQRVY2T19rR2VEa2I4Q1JkQSZhbXA7c2lnMj1VQ3JQ blJvNjQtVEc1LTNEZ1ljbHFRJmFtcDtidm09YnYuOTg3MTc2MDEsZC5iR2c8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5TaW5jZSBhIHN0cm9uZyBtb3RpdmF0aW9uIGZvciBUUkFNLCBhcyBJIHVuZGVy c3RhbmQgaXQsIGlzIHRoZSBzaGlmdCB0b3dhcmRzIHVzaW5nIFNUVU4vVFVSTiBmb3IgV2ViUlRD LCBhbmQgdGhlIGJpZyB2YWx1ZSBpbiBXZWJSVEMgaXMgdGhlIGFsbW9zdCBzZXJ2ZXJsZXNzIG5h dHVyZSBvZiBXZWJSVEMsIEkgd2FzIHdvbmRlcmluZyBpZiB0aGlzIGdyb3VwIGlzIHRha2luZyBE SFQNCiBpbnRvIGNvbnNpZGVyYXRpb24/IElmIGF0IGxlYXN0IHRoZSBzaWduYWxpbmcgc2VydmVy IGFuZCB0aGUgU1RVTiBzZXJ2ZXIgY291bGQgYmUgc2hpZnRlZCB0byBESFQsIFdlYlJUQyBjb3Vs ZCBiZWNvbWUgdHJ1bHkgc2VydmVybGVzcyBmb3IgdGhlIG1ham9yaXR5IG9mIHVzZXJzIHRoYXQg ZG8gbm90IHJlcXVpcmUgYSBUVVJOIHNlcnZlciwgYW5kIHRoZXJlYnkgZXh0cmVtZWx5IHJlc2ls aWVudCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+L0tpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5TdGVmYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5TdGVmYW4gTcO2aGw8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tR0IiPiB8DQo8Yj5WZXJnaWMgQUI8L2I+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkNoaWVmIEluZnJhc3Ry dWN0dXJlIE9mZmljZXI8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6U1YiPuKYjjwvc3Bhbj48L2I+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlNW Ij4mIzQzOzQ2Jm5ic3A7NzM1LTIzDQogMTIgNTA8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOlNWIj5AOg0KPGEgaHJlZj0ibWFpbHRvOnN0ZWZhbkB2ZXJnaWMuY29tIj48c3BhbiBz dHlsZT0iY29sb3I6IzA1NjNDMSI+c3RlZmFuQHZlcmdpYy5jb208L3NwYW4+PC9hPjxicj4NCnc6 Jm5ic3A7PC9zcGFuPjwvYj48Yj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMkU3NEI1O21zby1m YXJlYXN0LWxhbmd1YWdlOlNWIj48YSBocmVmPSJodHRwOi8vd3d3LnZlcmdpYy5jb20vIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMyRTc0QjUiPnd3dy52ZXJnaWMuY29tPC9zcGFu PjwvYT48L3NwYW4+PC91PjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6U1YiPkZvbGxvdyB1cyBvbiB0d2l0dGVyOiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2NvbG9yOiMyRTc0QjU7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6U1YiPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vVmVyZ2ljQUIi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzJFNzRCNSI+VmVyZ2ljPC9zcGFuPjwv YT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6YmxhY2s7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6U1YiPkZvbGxvdyB1cyBvbiBMaW5rZWRpbjo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6IzJFNzRCNTttc28t ZmFyZWFzdC1sYW5ndWFnZTpTViI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Y29sb3I6IzJFNzRCNTttc28tZmFyZWFzdC1sYW5ndWFnZTpTViI+PGEgaHJlZj0iaHR0 cDovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS92ZXJnaWMiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzJFNzRCNSI+VmVyZ2ljPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpTViI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iREUi IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6U1YiPiZuYnNwOzwv c3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpTViI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOmJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOlNWIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjkyIiBoZWlnaHQ9IjQx IiBpZD0iUGljdHVyZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwMS5wbmdAMDFEMENBMUYuMTY0 MkZDMzAiIGFsdD0iY2lkOjAxOUVGN0NGLTNDQTQtNEQ2Qy04MDhELUFFMUI4RkRFN0RFNyI+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6U1Yi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0E2QTZBNjttc28tZmFyZWFzdC1sYW5ndWFnZTpT ViI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlLW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCBjb250YWluIHByb3ByaWV0YXJ5L0NvbmZpZGVudGlhbCBJbmZvcm1hdGlvbiBwcm90 ZWN0ZWQgYnkgbGF3DQogYW5kIGJlbG9uZ3MgdG8gVmVyZ2ljIEFCLCBhbmQgaXRzIGFmZmlsaWF0 ZXMuIElmIHlvdSBhcmUgbm90IGEgcmVjaXBpZW50IGluZGljYXRlZCBvciBpbnRlbmRlZCBpbiB0 aGlzIG1lc3NhZ2UgKG9yIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyeSBvZiB0aGlzIG1lc3NhZ2Ug dG8gc3VjaCBwZXJzb24pLCBvciB5b3UgdGhpbmsgZm9yIGFueSByZWFzb24gdGhhdCB0aGlzIG1l c3NhZ2UgbWF5IGhhdmUgYmVlbiBhZGRyZXNzZWQgdG8geW91IGluIGVycm9yLA0KIHlvdSBtYXkg bm90IHVzZSBvciBjb3B5IG9yIGRlbGl2ZXIgdGhpcyBtZXNzYWdlIHRvIGFueW9uZSBlbHNlLiBJ biBzdWNoIGNhc2UsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSByZXR1 cm5pbmcgdGhlIGUtbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgZnJvbSB5b3VyIHN5c3RlbS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR06MB1226ED5991A9C1322E9878BDB28C0HE1PR06MB1226eurp_-- --_004_HE1PR06MB1226ED5991A9C1322E9878BDB28C0HE1PR06MB1226eurp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4676; creation-date="Wed, 29 Jul 2015 14:53:24 GMT"; modification-date="Wed, 29 Jul 2015 14:53:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFwAAAApCAYAAAC4AE4qAAAEJGlDQ1BJQ0MgUHJvZmlsZQAAOBGF Vd9v21QUPolvUqQWPyBYR4eKxa9VU1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8 AUDZAw9IPCENBmJ72fbAtElThyqqSUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWa GVWIlquunc8klZOnFpSeTYrSs9RLA9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJP wG4VHX0Z+AxRzNRrtksUvwf7+Gm3BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzY Zi+3YV8DGMiT4VVuG7oiZpGzrZJhcs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0 HPBLsF+vuUlhfwX4j/rSfAJ4H1H0qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgj ONd1ZxKzpBeA71b4tNhj6JGoyFNp4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyo Bc3SOjczohbyS1drbq6pQdqumllRC/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrY BbueF9qQn93S7HQGGHnYP7w6L+YGHNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiE hcPLYTEiT9ISbN15OY/jx4SMshe9LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrB DgUKcm06FSrTfSj187xPdVQWOk5Q8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfS Pqdraz/sDjzKBrv4zu2+a2t0/HHzjd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1c AdMlDetv4FnQ2lLasaOl6vmB0CMmwT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0n fS/9TIp0Wboi/SRdlb6RLgU5u++9nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8e k6fkvfDsCfbNDP0dvRh0CrNqTbV7LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWW ing6noonSInvi0/Ex+IzAreevPhe+CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8O okmrdtY2yhVX2a+qrykJfMq4Ml3VR4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/ wjvrVmhbqBN97RD1vxrahvBOfOYzoosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83 Gv+uNxo7XyL/FtFl8z9ZAHF4bBsrEwAADdtJREFUaAXtWgtQlNcV/vbhLuxieIgKob7IQ9HxVY1K KIoTqQ9ixYmpGpPUxGRsJk/jZGoyGWPTmJqxzmhqR81Uq5NRMS+lipKpKZj4rDFoLEEdRcQgD+Ul sLAvtve7m7v8uywKteI04Tjy//d17rnff+455567QBd1KgI6ztbc3Ozp1Fl/opPp9Xqd/ie69ju2 7C7AOxl6YyfP9381nbuqEjqHAx6TCYaoHv8T2bsADwKj42Ih7Ft3oynvW3jqGqDrboUx4V5YH0mD aeSwICPaX9XlNAOwsp04gYY//AWeiko0C4Orxw862eyCLiwMlhcfh3X61IBR7SvSaXZpuAYrd3kF 7Cs3wXOtFq5QM0JHDYVpQDzspVfg+OY09DUNsH2QAd3A/rDcn6AZ2f7XLsA1WNm+OAB7SSkg9r1l 3q8Q8fTjstUq/jbs3oeGP2+Bu7oG7t25wOLggDdebYDH5oQx3AxTRKiGu/e1C3ANJK7vzgMeN4wD +qB7ur/ZoBmx5x6C68hpNJ05D0uDDQarxTf6Us5ZXN70NWrPlcPT6IY+zIjocX0R/3wyou/p5evX BbgPCoF1YwP0zcJuh4cHjUr0PaOgc7mha7JrRgHnNx1H/p++QHODU9Z7jKJPrQEln36Ha0eLMWbt rxH98zjZJgFfvnw5CgoKZMXEiROxYMECP4aqsHHjRuTk5MBub8Ls2XMwa9Ys2XTo0CHk5uaiqOgi GhubVHfZb8qUqZLftm3bsHfvXoSGhvjatS8ct2jRIowaNUpWZ2Vl4dixYygV9lPLU42ZP38+Jk2a hP3792PDhvUwm0Og6lQfPtlOPsFk066BfQlos8EA96XvwUiF9ltRc101XPmFIkQ0w8AP8oN2lx4q RMGq/dA5PegWHoJeKfEIiYvA9X+XCbCL4CppRN6STPxi628kKwn4iBEjsGbNallx+PBBjBs3DkOG DFFzyWd+fj7ee++PqKmpFYszYcmS13H9ei0WL16M7Ox9AlyHX38WbLZG9O8/QNavW7cOZ8+eadVH VbDv3LlzxRgbXn75JWRl7YbLJdQtCLndTtTW1kjAKyoqsG9ftpDJ6KvjkMrKSrz2mle2YHzq6urF OhP9uIeMHgnHnkPwVNagftVGRLz8JDx394FL8Gr4awZcRVfEDhAm58GW0LDwoxNw1bugF/Z66PJf ot/DLW3fvJON4i0nUHehAhc+ypNzScCp1cOHD0d+/mnU1zcIALNbAc46gk2aMGGi1MSXXnoRn332 CSwWq/wIkZFRMIlDgqLQUAvS09MliKwzGvUwGLxWrGfPntDrDaorYmNjkZCQgLfeeguZmZmSH+BC WFh3hISEirEG8QHcqK6ugtvdckDmfBYL2/VwuV0+fkuW/A579mRJPkJpEShbZGQkUlJSfP35EjJp Imxffg3X/oNwnCpAxaLlMEbeBU9NHZxCITirfugQWKdMkuPcwo7Xf1su33uNifMDm5UJC5NRtrcA rquNKN56XPaTq7dYLJgxIx2nTp2Sgufm5uC5554TC/E6BWodtVgRNZEav3PnZxLs0NBQLFv2NiZP nixMRotnVuOpbYq4E5544nG88cabrfqeEDFwRsY2CZJbgDdv3pPSTMTExMjhR48exVNPzZcyKn7B njRxlJc7kfK8++4KUKmCyRY4PvyVp3FdxNzO3K/RLBTMVVsPvUcHvc4D0/AEhC1e4LPvbqcOLpt3 Z5t7dw9khdCeVnQLM0vACTrJq27iZdq0aXj//dXCXjbi5Mk8adOVPc3Ly8OZMwVyoffcc78UftOm TT4zkpycjMcee0wybM+fxMQk9OjR+qjMXcQPQm1NSkrGypUr/dhFRET4ldsq0J8oE5eamurzNW31 19bzCB/5zutwHD4O+xGh7eXXoIuyguamW+JYn+3mGL3JAHPsXXCUNaBK2GyCb7S07PBr35TAVm6D R/yLGt0HuKABPD4+XpiKFLmdyYyLV4Dv2rXLt4ApU6ZIzT937iy7SS0qKioCzUsgRUREClu/JLC6 zTI/NIk2NzXVu23b7HyDBjpIRTExseq1Q0/Tgw+A/29EBLdnUh/Y8ipQn1+O42/vwbDnJ8Lcw4qa M1eR9+4e6Goc0Jl0GPD0g8AODeBknJ4+0+esCDijBmp8Ts4/pdbRntImk6qqquWTfy5fvozz58Xn C6C+fftKwLVbOaCLX7GpqSXCCQu7y6+tI4WamhopbzBneSM+PNx4xMFH161FSwP7e5wCwOhIhEyd LLX93ieSUPaPC7CdrcTVT8/gYM73Iqw0wi60vrnRCbf4Fzd9MPqk3itZ+UwKS4xOGFVQQ4qKCkFT UlpaiuLiYtl5zJiW6EUb3hFQOkGScoQOkWWjI+wIhYS0hIwuV+uo52a8ZGJIdGKIqMA2GrvdbJhs d7uaYM/OgfPYaaGRbQPOONwY3w+hk1PEOAusMWEYuzodJ9/MQvWJMtjKRGBR5p1SZ9Ij7pHBGLF0 mrdC/PUDnHaVcfPatWuFwA7QlBBwEu0qnaUiFe7RVjJqWbNmjWrye9Jxap2mX2NAQfuBTp/OD2ht f1HLp6amZSfeiIPBGCLi6Ai4Y8Wp0OQHi/8whwseYTI8erOvPmLw3Uj+cB6K913A1cPn4K5zgE40 dupgxCbF+/rxpRXntLSHsXnz3+B0OoU93ymAd0mwlbNUoxm7kxgJ0KHSHMTFeU9Tqk9Hn+PHTxBR Sobk+fnn2Zg+PQ3jx6f42Gh3gK9S86LuCUeOHIktWzZLPnl5J1FSUtIu2ayvi8jMKWL/Zu+JUcPa /1Xfzc95spEHoQGzhsr//p39S60Ap6OkwF99ddDXk9tTOUtVqWJ3hpLl5WV49NFHMHr0A4iOjlZd YLWGybCuvTZcy5Px9jPPPCPOByNw3333SV40dfzADBmDkcvprWd4Sv9BU0jTOGfOHLGmEaATV/F8 uDgtzhenVW201Jh7FPi+Smi4+nTBZhF14SJqEbkWp0uP8xv/JWx1+81fK8A5xYwZM3yAc3EREeE+ Z6lEoKlYtuz3Il7/LcrKyqTTpOPkKdBg8NpNnh5JjOlZr+xqszitBSMunjyffXYBrl2rlMAeOHAA /K+IgAcjxZtt5LNixXt49dVFUjaecANPuZSNYaY2jUEb7j7+Hdwi3GNOJRhRdkNcb68Nb7aiaMMR OGtbnH2wMdq6oIA/9FAqBg4cJI/KTU2N0q4HHvXJJCkpSdj5TGGCNsscS0NDnQC1BUyOVZFHXNzP 4HA4xS8E3FJbtUJo38nzww+3Yv36ddJp0/lqiZofSFQIo9EoAVRtzLNs354hZeOBiakALVE2RmCK 6DR14vTp7hUFg7ltR6sTP3AwxHoPYvTH5hgrdKEG6AzKZXs5etyeVnW4LDO/wX8mQbtnt9vlaG4/ 7dZTQmqfPI1WV1fLMfKY/UMeRI1lu1rgzXgpvoqnKh85ckTE+8/LnTJhwgR8/PEnMm3AHUYym81B bbXio91l7K9k4ztJ3WF6S23/1d5xMv/dXrL27t72jU9HHSBNjDrKBxPgZu3aMQRIEXMeHMtI58sv W0yLipLYxkPbjai9c3f0opgny4I1OXBdF4oZ1Fa0lqqd3VoPvB01BHrFihXSPAXyb2y0SefM5BdD 1sDEU2D/zig7Rf77yt8Lbt2Gd4awweagaWDy6sqVMmEejNL50gyQlCPmO6MORjR3mkwWnbThvN0x ajKfbcp1Ixve5qDb2ECzQQ3nBUcwYlg3duxYpKWlBWu+I3UqW9ieyU1hITrpWrt+W9geuG69T9dv C28dww5zaOU06bhUmKUNm1SYyIiAfej5STQDDPMKCwtlme2sq62t9Qu7OIZhoYrL2VlFQlrerNeO 5ymV8mhl4VzaEJBlXlKoaIb9eahpiz/nuFPkBzgXun79eikLj+u9e8fIE2apSGDxIpaL5sIIQv/+ /WVii6lQHk7Yp1+/fjIWZ2qX/Zhv4ccgoKxjmU+OYZRBQDjn6tWrMWjQIHGDtBMzZ86UhxXyYn/G 3jwP8ENxzKVLl0RquApRUVHyhmn79u1SXt5tLly4UI6lnPzgtPcMKzkn6yg35+H8d8oP+AHOdOzA gQPl3WJBQYF88pRGYt6BADGTSDB5e0964YUXwFt/ZhKp3bwmI2mPzCxzkepCgxqoFkwgCS77kzfn U2WOI+BMDXAMb/0JPtPIPJFSs1nmRTZv55kCYIKLMvFD8mMQZOaBOPeqVaukHOoARv6dTX6Ac3J1 jUWtpbAkCrhhwwa5jVkm4JmZu0TdByzKRVM7OZbAE5ylS5fKjxR4KCHAgQs+deok+BMMEsHesSND gs8kGgFl5MI06yuvLJKaylQCNZ3KoeRlSpZ1JJovLTEDyWs3ysXL8sD5tX1v97s+cAK1fVU9hSPw s2fPlgBya5LmzJkrNYiLoz3lDqCW0o5Se5kAIzDtIZ4aqYXUTGooM4R8pxaTN+dmSMh3mihq9MWL F0VC6qwPvCJxzadkC5yTt1SUj4rC9d1J8tNwpdFcNH9+wAXSVvKdmkR7yDL78ScNtNu8pKCm0fZz QTyQ0NxQm4YN8/5Gg/yUJvJdzaMWznHKwfGdmkrzQg3nfKzjB6Qtpg2m6SMxn8I6mgruHILKeRVx Hv7n3PxQfNL37NixQ/ZLTEz0mTk15nY/bzkOVxELbSYXTeDoJAksF/nfEHkyEabyKIqHMhWBbZxP 9VXyqDHap2pri7+27+14Zxx+y4DfDsF+rDy7Dj4/1i/bta4WBP4DohpObCg0ulQAAAAASUVORK5C YII= --_004_HE1PR06MB1226ED5991A9C1322E9878BDB28C0HE1PR06MB1226eurp_-- From nobody Thu Jul 30 11:23:42 2015 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 7E5BF1A8A5A for ; Thu, 30 Jul 2015 11:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 oKOFg9KI_QQ8 for ; Thu, 30 Jul 2015 11:23:38 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CD01A8A65 for ; Thu, 30 Jul 2015 11:23:38 -0700 (PDT) Received: by wibud3 with SMTP id ud3so2981990wib.0 for ; Thu, 30 Jul 2015 11:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=BdQkifjxVbzQs14ye4aF0rMs09cxHfxBfQGjwKkx7us=; b=kZ3REcFQjMN0ZzaPHo6DD5ozfANVL1i8bN7QCTY7DIkjydZgnIAfOnYTGn9+StUo+I mZjyNSakWXY4zb/Rkv07KTORVvnKe31KHSk+0vVcrzuVusu8N8qyg6Dp3uyCf+uSIjvu K8xzwdg8cdqK37F76rM+LePMO/QhWEr4xdrhJItwfivuwn1yupDnrIiCuPyLqvkDJ1aw 2l4c8Ja0LuHX4ijdO5YrS7pnDqs0I78GOIS6SZmdae6dAf5PzNr5RN7f9YclhRMpNPAv jNBwAQ/qPeRgiNsg27J/FuubBy7pNd+/3fb9CS8DcqAx65bg2YDh0+g2kAGALkadhoDe 7d8w== X-Received: by 10.194.204.163 with SMTP id kz3mr29822711wjc.28.1438280616961; Thu, 30 Jul 2015 11:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.24.88 with HTTP; Thu, 30 Jul 2015 11:23:17 -0700 (PDT) From: Bernard Aboba Date: Thu, 30 Jul 2015 11:23:17 -0700 Message-ID: To: tram@ietf.org Content-Type: multipart/alternative; boundary=047d7bae431e42ee73051c1bcda1 Archived-At: Subject: [tram] Review of draft-ietf-tram-turn-server-discovery-04 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, 30 Jul 2015 18:23:40 -0000 --047d7bae431e42ee73051c1bcda1 Content-Type: text/plain; charset=UTF-8 1. Overall, in reading this document it was not clear to me how it was intended to be applied to WebRTC scenarios where a TURN server is configured in the JS. * Does TURN server discovery apply in this case, or is the JS-specified TURN server considered "manual TURN configuration" ? * Where IdP is used, is the local IdP identity considered to consitute a "domain name" per Section 4.1.2? 2. In scenarios where TURN Server discovery does apply, what mechanisms are to be used to authenticate or authorize the discovered TURN Servers(s)? Using a configured domain name seems like a potentially viable approach, but there are scenarios where that might not be configured, or might not be secure (e.g. if the domain name were obtained from unauthenticated DHCP). Using the browser's configured trust anchor(s) doesn't seem like a good idea, given that it would only be as secure as the least-secure trust anchor. Specific comments: Section 3 1. Local Configuration : Local or manual TURN configuration (i.e., TURN servers configured at the system level) should be tried first, as it may be an explicit preferred choice of a user. [BA] Would TURN servers specified within a WebRTC JS application be considered "local or manual" in this context? Also, shouldn't a configured domain name (Section 4.1.2) be considered part of "local TURN configuration"? IMHO, the configured domain name not only enables discovery as indicated in Section 4.2, but also provides a mechanism for validation of the TURN server discovered by other methods. The document does not prescribe a strict order that a client must follow for discovery. An implementation may choose to perform steps 2,3 and 4 in parallel for discovery OR choose to follow any desired order and stop the discovery procedure if a mechanism succeeds. [BA] I am not sure I buy this. It is already stated that "local or manual" configuration should be tried first, and I would considered a configured domain name to be part of this, which would imply attempting 2 first if that exists. Section 9.2 For mDNS, in addition to what has been described above, a principal security threat is a security threat inherent to IP multicast routing and any application that runs on it. A rogue system can advertise that it is a TURN server. Discovery of such rogue systems as TURN servers, in itself, is not a security threat if there is a means for the TURN client to authenticate and authorize the discovered TURN servers. [BA] In scenarios in which mDNS would be used, there typically will not be a means for the TURN client to authentication and authorize the discovered TURN server. For example, a home router with a built-in TURN server is not likely to have a certificate chaining to a trust anchor. Also, the mDNS is not compatible with DNSSEC (e.g. there is no signer for the .local domain). Section 9.3 Sensitive clients that do not wish to leak information about their presence can set an IP TTL on their TURN requests that limits how far they can travel into the public Internet. [BA] This seems like a crude tool at best. If the goal is to provide privacy, wouldn't use of encryption make more sense? This could include DNS privacy, encryption of TURN traffic, etc. --047d7bae431e42ee73051c1bcda1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
1. Overall, in reading this document it was not clear= to me how it was intended
to be applied to WebRTC scenarios wher= e a TURN server is configured in the JS.=C2=A0

* D= oes TURN server discovery apply in this case, or is the JS-specified TURN s= erver considered "manual TURN configuration" ?=C2=A0
* Where IdP is used, is the local IdP identity considered to c= onsitute a "domain name" per Section 4.1.2? =C2=A0

=
2. In scenarios where TURN Server discovery does apply, what mec= hanisms are to be used to authenticate or authorize the discovered TURN Ser= vers(s)?=C2=A0 Using a configured domain name seems like a potentially viab= le approach, but there are scenarios where that might not be configured, or= might not be secure
(e.g. if the domain name were obtained from = unauthenticated DHCP). =C2=A0

Using the browser= 9;s configured trust anchor(s) doesn't seem like a good idea, given tha= t it would only be as secure as the least-secure trust anchor.=C2=A0
<= div>
Specific comments:=C2=A0

Sectio= n 3

=C2=A0 =C2=A01.=C2=A0 Local Configuration : Lo= cal or manual TURN configuration (i.e.,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0TURN servers configured at the system level) should be tried
= =C2=A0 =C2=A0 =C2=A0 =C2=A0first, as it may be an explicit preferred choice= of a user.

[BA] Would TURN servers specified with= in a WebRTC JS application be considered "local or manual" in thi= s context?=C2=A0 Also, shouldn't a configured domain name (Section 4.1.= 2) be considered part of "local TURN configuration"?=C2=A0
<= div>
IMHO, the configured domain name not only enables discov= ery as indicated
in Section 4.2, but also provides a mechanism fo= r validation of the
TURN server discovered by other methods. =C2= =A0=C2=A0

=C2=A0 =C2=A0The document does not presc= ribe a strict order that a client must
=C2=A0 =C2=A0follow for di= scovery.=C2=A0 An implementation may choose to perform steps
=C2= =A0 =C2=A02,3 and 4 in parallel for discovery OR choose to follow any desir= ed
=C2=A0 =C2=A0order and stop the discovery procedure if a mecha= nism succeeds.

[BA] I am not sure I buy this.=C2= =A0 It is already stated that "local or manual" configuration sho= uld be tried first, and I would considered a configured domain name to be p= art of this, which would imply attempting 2 first if that exists. =C2=A0=C2= =A0

Section 9.2

=C2=A0 = =C2=A0For mDNS, in addition to what has been described above, a principal
=C2=A0 =C2=A0security threat is a security threat inherent to IP m= ulticast routing
=C2=A0 =C2=A0and any application that runs on it= .=C2=A0 A rogue system can advertise
=C2=A0 =C2=A0that it is a TU= RN server.=C2=A0 Discovery of such rogue systems as TURN
=C2=A0 = =C2=A0servers, in itself, is not a security threat if there is a means for<= /div>
=C2=A0 =C2=A0the TURN client to authenticate and authorize the di= scovered TURN
=C2=A0 =C2=A0servers.

[BA]= In scenarios in which mDNS would be used, there typically will not be a
means for the TURN client to authentication and authorize the disco= vered
TURN server. For example, a home router with a built-in TUR= N server is
not likely to have a certificate chaining to a trust = anchor.=C2=A0 Also, the
mDNS is not compatible with DNSSEC (e.g. = there is no signer for the .local
domain). =C2=A0

<= /div>
Section 9.3

=C2=A0 =C2=A0Sensitive clien= ts that do not wish to leak information about their
=C2=A0 =C2=A0= presence can set an IP TTL on their TURN requests that limits how far
=
=C2=A0 =C2=A0they can travel into the public Internet.

<= /div>
[BA] This seems like a crude tool at best.=C2=A0 If the goal is t= o provide privacy,
wouldn't use of encryption make more sense= ?=C2=A0 This could include DNS privacy,
encryption of TURN traffi= c, etc.=C2=A0
--047d7bae431e42ee73051c1bcda1-- From nobody Thu Jul 30 11:31:40 2015 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 C9EC91B2D4F for ; Thu, 30 Jul 2015 11:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UXLMEuzcLTEi for ; Thu, 30 Jul 2015 11:31:37 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A92E1ACD2F for ; Thu, 30 Jul 2015 11:31:37 -0700 (PDT) Received: by iggf3 with SMTP id f3so1818962igg.1 for ; Thu, 30 Jul 2015 11:31:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0b7V9+BblDtA7o/Qkk+dIUI2HkWeUIAZTUpamARBQDY=; b=BF/6jnAv6rqIsKwRkwGBemFHLkRhhDx0uaS6naHRas3kJjrLrhLI1oiE2RM1IQMxZq tbc/P2nzv2e3dWY0G5XbtNfD7YAa9LuZTKaK9zI7cROUQHG8V0pzmdRMFpN2wX47VP3L 9rnxzdDNQUV2GyxYM/G3Scat5PzEw/J/GEbUbppn5TcNJLxgkZfkHfXMBkb6ger+vb0C 38DLt+fOIf5UX+xRoXaIfodNmnEpF0Zd2iD/gIRIFlQk3oGBpsiNBmhgiu+SMSKxIitR P7LzI1M3MXZqH1Da+45PbSuZyfG8Mpkl3gLdOyk8qm6VAwFd7KMngCB4FOXc05KDTK6l nffQ== X-Gm-Message-State: ALoCoQlyWDO5xDqRyMpc554mE/K97SOEPUwy0RiATsHrzr9bwaPWIQyEbO2xvk/NP9jfZ/Y/zx+A X-Received: by 10.50.79.169 with SMTP id k9mr7184643igx.63.1438281096700; Thu, 30 Jul 2015 11:31:36 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id q12sm1858906igr.2.2015.07.30.11.31.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 11:31:35 -0700 (PDT) Received: by iodd187 with SMTP id d187so62405638iod.2 for ; Thu, 30 Jul 2015 11:31:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.131.91 with SMTP id f88mr13161002iod.190.1438281094701; Thu, 30 Jul 2015 11:31:34 -0700 (PDT) Received: by 10.64.171.114 with HTTP; Thu, 30 Jul 2015 11:31:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 14:31:34 -0400 Message-ID: From: Benjamin Schwartz To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a113ecd56bcd13d051c1be90c Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Review of draft-ietf-tram-turn-server-discovery-04 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, 30 Jul 2015 18:31:40 -0000 --001a113ecd56bcd13d051c1be90c Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 2:23 PM, Bernard Aboba wrote: > 1. Overall, in reading this document it was not clear to me how it was > intended > to be applied to WebRTC scenarios where a TURN server is configured in the > JS. > > * Does TURN server discovery apply in this case, or is the JS-specified > TURN server considered "manual TURN configuration" ? > In WebRTC scenarios, RETURN specifies the correct handling of autodiscovered TURN servers. The conclusion, roughly, is that JS-specified TURN servers and autodiscovered TURN servers are configured independently, and under various conditions the client may use both simultaneously, neither, or either one of the two. I agree that the autodiscovery draft could be clearer about its interaction with WebRTC. > > * Where IdP is used, is the local IdP identity considered to consitute a > "domain name" per Section 4.1.2? > > 2. In scenarios where TURN Server discovery does apply, what mechanisms > are to be used to authenticate or authorize the discovered TURN > Servers(s)? Using a configured domain name seems like a potentially viable > approach, but there are scenarios where that might not be configured, or > might not be secure > (e.g. if the domain name were obtained from unauthenticated DHCP). > > Using the browser's configured trust anchor(s) doesn't seem like a good > idea, given that it would only be as secure as the least-secure trust > anchor. > > Specific comments: > > Section 3 > > 1. Local Configuration : Local or manual TURN configuration (i.e., > TURN servers configured at the system level) should be tried > first, as it may be an explicit preferred choice of a user. > > [BA] Would TURN servers specified within a WebRTC JS application be > considered "local or manual" in this context? Also, shouldn't a configured > domain name (Section 4.1.2) be considered part of "local TURN > configuration"? > > IMHO, the configured domain name not only enables discovery as indicated > in Section 4.2, but also provides a mechanism for validation of the > TURN server discovered by other methods. > > The document does not prescribe a strict order that a client must > follow for discovery. An implementation may choose to perform steps > 2,3 and 4 in parallel for discovery OR choose to follow any desired > order and stop the discovery procedure if a mechanism succeeds. > > [BA] I am not sure I buy this. It is already stated that "local or > manual" configuration should be tried first, and I would considered a > configured domain name to be part of this, which would imply attempting 2 > first if that exists. > > Section 9.2 > > For mDNS, in addition to what has been described above, a principal > security threat is a security threat inherent to IP multicast routing > and any application that runs on it. A rogue system can advertise > that it is a TURN server. Discovery of such rogue systems as TURN > servers, in itself, is not a security threat if there is a means for > the TURN client to authenticate and authorize the discovered TURN > servers. > > [BA] In scenarios in which mDNS would be used, there typically will not be > a > means for the TURN client to authentication and authorize the discovered > TURN server. For example, a home router with a built-in TURN server is > not likely to have a certificate chaining to a trust anchor. Also, the > mDNS is not compatible with DNSSEC (e.g. there is no signer for the .local > domain). > > Section 9.3 > > Sensitive clients that do not wish to leak information about their > presence can set an IP TTL on their TURN requests that limits how far > they can travel into the public Internet. > > [BA] This seems like a crude tool at best. If the goal is to provide > privacy, > wouldn't use of encryption make more sense? This could include DNS > privacy, > encryption of TURN traffic, etc. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --001a113ecd56bcd13d051c1be90c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 30, 2015 at 2:23 PM, Bernard Aboba <bernard.aboba@gmail.com<= /a>> wrote:
1. Overall, in reading this document it was not clear to me how it was i= ntended
to be applied to WebRTC scenarios where a TURN server is = configured in the JS.=C2=A0

* Does TURN server dis= covery apply in this case, or is the JS-specified TURN server considered &q= uot;manual TURN configuration" ?

In WebRTC scenarios, RETURN specifies the correct handling of autodi= scovered TURN servers.=C2=A0 The conclusion, roughly, is that JS-specified = TURN servers and autodiscovered TURN servers are configured independently, = and under various conditions the client may use both simultaneously,=C2=A0n= either, or either one of the two.

I agree that the= autodiscovery draft could be clearer about its interaction with WebRTC.
=C2=A0
* Where IdP is used, is the local IdP identity considered to c= onsitute a "domain name" per Section 4.1.2? =C2=A0

=
2. In scenarios where TURN Server discovery does apply, what mec= hanisms are to be used to authenticate or authorize the discovered TURN Ser= vers(s)?=C2=A0 Using a configured domain name seems like a potentially viab= le approach, but there are scenarios where that might not be configured, or= might not be secure
(e.g. if the domain name were obtained from = unauthenticated DHCP). =C2=A0

Using the browser= 9;s configured trust anchor(s) doesn't seem like a good idea, given tha= t it would only be as secure as the least-secure trust anchor.=C2=A0
<= div>
Specific comments:=C2=A0

Sectio= n 3

=C2=A0 =C2=A01.=C2=A0 Local Configuration : Lo= cal or manual TURN configuration (i.e.,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0TURN servers configured at the system level) should be tried
= =C2=A0 =C2=A0 =C2=A0 =C2=A0first, as it may be an explicit preferred choice= of a user.

[BA] Would TURN servers specified with= in a WebRTC JS application be considered "local or manual" in thi= s context?=C2=A0 Also, shouldn't a configured domain name (Section 4.1.= 2) be considered part of "local TURN configuration"?=C2=A0
<= div>
IMHO, the configured domain name not only enables discov= ery as indicated
in Section 4.2, but also provides a mechanism fo= r validation of the
TURN server discovered by other methods. =C2= =A0=C2=A0

=C2=A0 =C2=A0The document does not presc= ribe a strict order that a client must
=C2=A0 =C2=A0follow for di= scovery.=C2=A0 An implementation may choose to perform steps
=C2= =A0 =C2=A02,3 and 4 in parallel for discovery OR choose to follow any desir= ed
=C2=A0 =C2=A0order and stop the discovery procedure if a mecha= nism succeeds.

[BA] I am not sure I buy this.=C2= =A0 It is already stated that "local or manual" configuration sho= uld be tried first, and I would considered a configured domain name to be p= art of this, which would imply attempting 2 first if that exists. =C2=A0=C2= =A0

Section 9.2

=C2=A0 = =C2=A0For mDNS, in addition to what has been described above, a principal
=C2=A0 =C2=A0security threat is a security threat inherent to IP m= ulticast routing
=C2=A0 =C2=A0and any application that runs on it= .=C2=A0 A rogue system can advertise
=C2=A0 =C2=A0that it is a TU= RN server.=C2=A0 Discovery of such rogue systems as TURN
=C2=A0 = =C2=A0servers, in itself, is not a security threat if there is a means for<= /div>
=C2=A0 =C2=A0the TURN client to authenticate and authorize the di= scovered TURN
=C2=A0 =C2=A0servers.

[BA]= In scenarios in which mDNS would be used, there typically will not be a
means for the TURN client to authentication and authorize the disco= vered
TURN server. For example, a home router with a built-in TUR= N server is
not likely to have a certificate chaining to a trust = anchor.=C2=A0 Also, the
mDNS is not compatible with DNSSEC (e.g. = there is no signer for the .local
domain). =C2=A0

--001a113ecd56bcd13d051c1be90c-- From nobody Thu Jul 30 11:36:54 2015 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 2A30D1B2F27 for ; Thu, 30 Jul 2015 11:36:53 -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 QWLXOjWDvLz1 for ; Thu, 30 Jul 2015 11:36:50 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D9B1B2F24 for ; Thu, 30 Jul 2015 11:36:50 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so3435564wic.1 for ; Thu, 30 Jul 2015 11:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yWO3GcgBy7qKaIRApCNj8YVCPmY1V2+v6iob0UyD01A=; b=krUU/R01/1gffRrEwfCrEjRE7En1aMnjVUg0VNDNkGwTJDlMjwf3QdO8AZvVstOLSD PePk6zPz2xizCuInxeToOUdbzH6smmZDxODP1T3ycfD4gg68F6syhDiIuhGylmsIzuf0 Cg6h8PBuZryoCkQ1lEBH8YEYgPhpcNYEgErPkKpUFnVeqk0OXu/tlDoh3GRSOAg1Sud7 u2WNJFYaEA00ha3YoUTAXEhhokkDSzVynK9RWG3upc+uJnk8FP1yYpYRMXmm7yoXMbt9 SbuPlueNtuJOrBTVXGqZlGSy5qpHPV2Rc45e0LVj2iv4ChKS4G9ohTRASeEChFGxlpum YX/A== X-Received: by 10.180.86.73 with SMTP id n9mr8830410wiz.78.1438281409167; Thu, 30 Jul 2015 11:36:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.24.88 with HTTP; Thu, 30 Jul 2015 11:36:29 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 30 Jul 2015 11:36:29 -0700 Message-ID: To: Benjamin Schwartz Content-Type: multipart/alternative; boundary=f46d0442806e7b06d3051c1bfcc8 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Review of draft-ietf-tram-turn-server-discovery-04 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, 30 Jul 2015 18:36:53 -0000 --f46d0442806e7b06d3051c1bfcc8 Content-Type: text/plain; charset=UTF-8 Benjamin said: "In WebRTC scenarios, RETURN specifies the correct handling of autodiscovered TURN servers. " [BA] It seems like RETURN could be relevant beyond Web-based scenarios (e.g. use in a mobile application). But the draft doesn't mention RETURN at all. On Thu, Jul 30, 2015 at 11:31 AM, Benjamin Schwartz wrote: > On Thu, Jul 30, 2015 at 2:23 PM, Bernard Aboba > wrote: > >> 1. Overall, in reading this document it was not clear to me how it was >> intended >> to be applied to WebRTC scenarios where a TURN server is configured in >> the JS. >> >> * Does TURN server discovery apply in this case, or is the JS-specified >> TURN server considered "manual TURN configuration" ? >> > > In WebRTC scenarios, RETURN specifies the correct handling of > autodiscovered TURN servers. The conclusion, roughly, is that JS-specified > TURN servers and autodiscovered TURN servers are configured independently, > and under various conditions the client may use both > simultaneously, neither, or either one of the two. > > I agree that the autodiscovery draft could be clearer about its > interaction with WebRTC. > > >> >> * Where IdP is used, is the local IdP identity considered to consitute a >> "domain name" per Section 4.1.2? >> >> 2. In scenarios where TURN Server discovery does apply, what mechanisms >> are to be used to authenticate or authorize the discovered TURN >> Servers(s)? Using a configured domain name seems like a potentially viable >> approach, but there are scenarios where that might not be configured, or >> might not be secure >> (e.g. if the domain name were obtained from unauthenticated DHCP). >> >> Using the browser's configured trust anchor(s) doesn't seem like a good >> idea, given that it would only be as secure as the least-secure trust >> anchor. >> >> Specific comments: >> >> Section 3 >> >> 1. Local Configuration : Local or manual TURN configuration (i.e., >> TURN servers configured at the system level) should be tried >> first, as it may be an explicit preferred choice of a user. >> >> [BA] Would TURN servers specified within a WebRTC JS application be >> considered "local or manual" in this context? Also, shouldn't a configured >> domain name (Section 4.1.2) be considered part of "local TURN >> configuration"? >> >> IMHO, the configured domain name not only enables discovery as indicated >> in Section 4.2, but also provides a mechanism for validation of the >> TURN server discovered by other methods. >> >> The document does not prescribe a strict order that a client must >> follow for discovery. An implementation may choose to perform steps >> 2,3 and 4 in parallel for discovery OR choose to follow any desired >> order and stop the discovery procedure if a mechanism succeeds. >> >> [BA] I am not sure I buy this. It is already stated that "local or >> manual" configuration should be tried first, and I would considered a >> configured domain name to be part of this, which would imply attempting 2 >> first if that exists. >> >> Section 9.2 >> >> For mDNS, in addition to what has been described above, a principal >> security threat is a security threat inherent to IP multicast routing >> and any application that runs on it. A rogue system can advertise >> that it is a TURN server. Discovery of such rogue systems as TURN >> servers, in itself, is not a security threat if there is a means for >> the TURN client to authenticate and authorize the discovered TURN >> servers. >> >> [BA] In scenarios in which mDNS would be used, there typically will not >> be a >> means for the TURN client to authentication and authorize the discovered >> TURN server. For example, a home router with a built-in TURN server is >> not likely to have a certificate chaining to a trust anchor. Also, the >> mDNS is not compatible with DNSSEC (e.g. there is no signer for the .local >> domain). >> >> Section 9.3 >> >> Sensitive clients that do not wish to leak information about their >> presence can set an IP TTL on their TURN requests that limits how far >> they can travel into the public Internet. >> >> [BA] This seems like a crude tool at best. If the goal is to provide >> privacy, >> wouldn't use of encryption make more sense? This could include DNS >> privacy, >> encryption of TURN traffic, etc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > --f46d0442806e7b06d3051c1bfcc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Benjamin said:=C2=A0
"In WebRTC scenarios, RETURN specifies the correct handling of autodis= covered TURN servers.=C2=A0=C2=A0"

[BA] It seems like RETURN could be rel= evant beyond Web-based scenarios (e.g. use in a mobile application).=C2=A0 = But the draft doesn't mention RETURN at all. =C2=A0

On Thu, Jul 30, 2015 at 1= 1:31 AM, Benjamin Schwartz <bemasc@webrtc.org> wrote:
On Thu, Jul 30, 2015 at 2:23 PM, B= ernard Aboba <bernard.aboba@gmail.com> wrote:
1. Overall, in reading this= document it was not clear to me how it was intended
to be applie= d to WebRTC scenarios where a TURN server is configured in the JS.=C2=A0

* Does TURN server discovery apply in this case, or = is the JS-specified TURN server considered "manual TURN configuration&= quot; ?

In WebRTC scenar= ios, RETURN specifies the correct handling of autodiscovered TURN servers.= =C2=A0 The conclusion, roughly, is that JS-specified TURN servers and autod= iscovered TURN servers are configured independently, and under various cond= itions the client may use both simultaneously,=C2=A0neither, or either one = of the two.

I agree that the autodiscovery draft c= ould be clearer about its interaction with WebRTC.
=C2=A0
<= br>
* Where IdP is used, is the local IdP identity considered to = consitute a "domain name" per Section 4.1.2? =C2=A0
2. In scenarios where TURN Server discovery does apply, what me= chanisms are to be used to authenticate or authorize the discovered TURN Se= rvers(s)?=C2=A0 Using a configured domain name seems like a potentially via= ble approach, but there are scenarios where that might not be configured, o= r might not be secure
(e.g. if the domain name were obtained from= unauthenticated DHCP). =C2=A0

Using the browser&#= 39;s configured trust anchor(s) doesn't seem like a good idea, given th= at it would only be as secure as the least-secure trust anchor.=C2=A0
=

Specific comments:=C2=A0

Secti= on 3

=C2=A0 =C2=A01.=C2=A0 Local Configuration : L= ocal or manual TURN configuration (i.e.,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0TURN servers configured at the system level) should be tried
= =C2=A0 =C2=A0 =C2=A0 =C2=A0first, as it may be an explicit preferred choice= of a user.

[BA] Would TURN servers specified with= in a WebRTC JS application be considered "local or manual" in thi= s context?=C2=A0 Also, shouldn't a configured domain name (Section 4.1.= 2) be considered part of "local TURN configuration"?=C2=A0
<= div>
IMHO, the configured domain name not only enables discov= ery as indicated
in Section 4.2, but also provides a mechanism fo= r validation of the
TURN server discovered by other methods. =C2= =A0=C2=A0

=C2=A0 =C2=A0The document does not presc= ribe a strict order that a client must
=C2=A0 =C2=A0follow for di= scovery.=C2=A0 An implementation may choose to perform steps
=C2= =A0 =C2=A02,3 and 4 in parallel for discovery OR choose to follow any desir= ed
=C2=A0 =C2=A0order and stop the discovery procedure if a mecha= nism succeeds.

[BA] I am not sure I buy this.=C2= =A0 It is already stated that "local or manual" configuration sho= uld be tried first, and I would considered a configured domain name to be p= art of this, which would imply attempting 2 first if that exists. =C2=A0=C2= =A0

Section 9.2

=C2=A0 = =C2=A0For mDNS, in addition to what has been described above, a principal
=C2=A0 =C2=A0security threat is a security threat inherent to IP m= ulticast routing
=C2=A0 =C2=A0and any application that runs on it= .=C2=A0 A rogue system can advertise
=C2=A0 =C2=A0that it is a TU= RN server.=C2=A0 Discovery of such rogue systems as TURN
=C2=A0 = =C2=A0servers, in itself, is not a security threat if there is a means for<= /div>
=C2=A0 =C2=A0the TURN client to authenticate and authorize the di= scovered TURN
=C2=A0 =C2=A0servers.

[BA]= In scenarios in which mDNS would be used, there typically will not be a
means for the TURN client to authentication and authorize the disco= vered
TURN server. For example, a home router with a built-in TUR= N server is
not likely to have a certificate chaining to a trust = anchor.=C2=A0 Also, the
mDNS is not compatible with DNSSEC (e.g. = there is no signer for the .local
domain). =C2=A0

<= /div>
Section 9.3

=C2=A0 =C2=A0Sensitive clien= ts that do not wish to leak information about their
=C2=A0 =C2=A0= presence can set an IP TTL on their TURN requests that limits how far
=
=C2=A0 =C2=A0they can travel into the public Internet.

<= /div>
[BA] This seems like a crude tool at best.=C2=A0 If the goal is t= o provide privacy,
wouldn't use of encryption make more sense= ?=C2=A0 This could include DNS privacy,
encryption of TURN traffi= c, etc.=C2=A0

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



--f46d0442806e7b06d3051c1bfcc8--