From nobody Sun Nov 1 18:22:58 2015 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E83FA1B4261; Sun, 1 Nov 2015 18:22:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102022255.31518.69191.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 18:22:55 -0800 Archived-At: Cc: tram-chairs@ietf.org, tram@ietf.org, The IESG Subject: [tram] WG Action: Rechartered TURN Revised and Modernized (tram) 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, 02 Nov 2015 02:22:56 -0000 The TURN Revised and Modernized (tram) working group in the Transport Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. TURN Revised and Modernized (tram) ------------------------------------------------ Current Status: Active WG Chairs: Gonzalo Camarillo Simon Perreault Assigned Area Director: Spencer Dawkins Mailing list Address: tram@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tram Archive: https://mailarchive.ietf.org/arch/browse/tram/ Charter: Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April 2010. For a few years, the protocol had seen rather limited deployment. This is largely because its primary use case is as one of the NAT traversal methods of the Interactive Connectivity Establishment (ICE) framework (RFC 5245), and ICE itself was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE, and consequently TURN, are mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. Together with the arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by recent work updating the ICE framework (still in progress), and standardizing the URIs used to access a STUN (RFC 7064) or TURN (RFC 7065) server. The goal of the TRAM Working Group is to consolidate the various initiatives to update TURN and STUN to make them more suitable for NAT traversal in a variety of environments, whether for realtime media establishment protocols such as the Offer-Answer Session Description Protocol (RFC 3264), XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), and RTCWeb (draft-ietf-rtcweb-jsep), or for non-realtime protocols such as HIP (RFC 5770) and RELOAD (RFC 6940). The work will include authentication mechanisms, a path MTU discovery mechanism, an IP address mobility solution for TURN, and extensions to TURN and STUN. The Working Group will closely coordinate with the appropriate Working Groups, including ICE, RTCWEB, MMUSIC, and HTTPBIS. In developing upgrades to TURN, the group will consider the passive monitoring risks introduced by the centralization of call traffic through a TURN server. When such risks arise, they will recommend appropriate mitigations. For example, a mechanism for directing traffic to a TURN server other than one configured by the application could be used to direct calls through a TURN server configured to do monitoring. When such a mechanism is used, it is important that the endpoints to the call apply end-to-end encryption and authentication to ensure that they are protected from the TURN server. Milestones: Nov 2015 - Send new TURN server discovery mechanism for enterprises and ISPs to IESG for publication as Proposed Standard Nov 2015 - Send path characteristic measurement mechanism to IESG for publication as Proposed Standard Nov 2015 - Adopt TURN PMTUD draft Nov 2015 - Adopt TURN IP address mobility draft Jan 2016 - Send STUN-bis draft to IESG for publication as Proposed Standard Jan 2016 - Send TURN-bis draft to IESG for publication as Proposed Standard Mar 2016 - Send new authentication mechanism(s) to IESG for publication as Proposed Standard Mar 2016 - Submit TURN PMTUD draft to IESG Jul 2016 - Submit TURN IP address mobility draft to IESG From nobody Sun Nov 1 19:52: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 9D4A41B336A for ; Sun, 1 Nov 2015 19:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5Sn8uV9F4gbj for ; Sun, 1 Nov 2015 19:52:55 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 575661B3370 for ; Sun, 1 Nov 2015 19:52:55 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id A78411EB841D for ; Mon, 2 Nov 2015 04:52:53 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 04:52:53 +0100 From: "Hutton, Andrew" To: "tram@ietf.org" Thread-Topic: turn-server-discover and return Thread-Index: AdEVIfNvPnqALUWVT4Cy8RvF8/IeTw== Date: Mon, 2 Nov 2015 03:52:53 +0000 Message-ID: <7247C6D7-A29F-406E-B5B5-417A56959C0F@unify.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <3D8F1A7430054C4CAAA2938C953D6482@unify.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tram] turn-server-discover and return 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, 02 Nov 2015 03:52:57 -0000 I am thinking that since this draft talks about enterprise use and WebRTC i= t should explain the relationshIp with the the rtcweb return draft. There is probably no impact on the mechanisms but still an explanation woul= d I think be a good idea. Regards Andy= From nobody Mon Nov 2 05:54: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 8454B1B36B4 for ; Mon, 2 Nov 2015 05:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rnOatDKsTBYJ for ; Mon, 2 Nov 2015 05:54:07 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 115E51B36B8 for ; Mon, 2 Nov 2015 05:54:06 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3E149423706 for ; Mon, 2 Nov 2015 13:54:06 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 285A347DD5 for ; Mon, 2 Nov 2015 13:54:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1446472446; bh=iNkJyoYnD4fbXR2x0HRTkldvdEUWsCc4o9a4nScwGpE=; l=1782; h=References:To:From:Date:In-Reply-To:From; b=IZcFb5sc5QYYLbc+K07XvZiT2j0pU9PEiNemNEWADFWB9Xf3D4lmXwg4Q+IG1Taix q1FGpMvioK/j/GjTdbf3F3halLZFwxQWxGAaAzBrZODjuxplU9IjQScYKYSmWAP9Om TZa+HBf/0Un1cG/VtUGIikFKzRGmEVcUYntOM7CA= Received: from [172.28.113.245] (bowill.kendall.corp.akamai.com [172.28.113.245]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 21C382046 for ; Mon, 2 Nov 2015 13:54:06 +0000 (GMT) References: <20151102134945.19405.37166.idtracker@ietfa.amsl.com> To: "tram@ietf.org" From: Brandon Williams X-Forwarded-Message-Id: <20151102134945.19405.37166.idtracker@ietfa.amsl.com> Message-ID: <56376AFE.4070705@akamai.com> Date: Mon, 2 Nov 2015 08:54:06 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151102134945.19405.37166.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-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, 02 Nov 2015 13:54:08 -0000 I just remembered that the submission tool is now open again, sorry for the delay. I have posted the updated version of our peer redirect draft. This is the version I will present on Thursday. If you've read one of the previous version of the document, your better off re-reading than viewing diffs, since some of the changes are substantial. See the change list in the appendix for details. --Brandon -------- Forwarded Message -------- Subject: New Version Notification for draft-williams-peer-redirect-04.txt Date: Mon, 2 Nov 2015 05:49:45 -0800 From: internet-drafts@ietf.org To: Tirumaleswar Reddy , Brandon Williams A new version of I-D, draft-williams-peer-redirect-04.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Name: draft-williams-peer-redirect Revision: 04 Title: Peer-specific Redirection for Traversal Using Relays around NAT (TURN) Document date: 2015-11-02 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-williams-peer-redirect-04.txt Status: https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ Htmlized: https://tools.ietf.org/html/draft-williams-peer-redirect-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-04 Abstract: This specification describes a peer-specific redirection method that allows the TURN server to redirect a client for the purpose of improving communication with a specific peer without negatively affecting communication with other peers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Nov 5 16:17:20 2015 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9EA1A6F7A; Thu, 5 Nov 2015 16:17:18 -0800 (PST) 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.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151106001718.32299.53644.idtracker@ietfa.amsl.com> Date: Thu, 05 Nov 2015 16:17:18 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-pmtud-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 00:17:18 -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 : Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : draft-ietf-tram-stun-pmtud-00.txt Pages : 11 Date : 2015-11-05 Abstract: This document describes a Session Traversal Utilities for NAT (STUN) usage for Path MTU Discovery (PMTUD) between a client and a server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-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/ From nobody Sat Nov 7 20:36:24 2015 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9151B317A; Sat, 7 Nov 2015 20:36:22 -0800 (PST) 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.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151108043622.19002.79331.idtracker@ietfa.amsl.com> Date: Sat, 07 Nov 2015 20:36:22 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.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: Sun, 08 Nov 2015 04:36:22 -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 : Mobility with TURN Authors : Dan Wing Prashanth Patil Tirumaleswar Reddy Paal-Erik Martinsen Filename : draft-ietf-tram-turn-mobility-00.txt Pages : 11 Date : 2015-11-07 Abstract: It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so only the local network elements are aware of the changed IP address but the remote peer is unaware of the changed IP address. This draft provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-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/ From nobody Tue Nov 10 10:54: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 03FBD1B3CCC for ; Tue, 10 Nov 2015 10:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, 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 Pfg77DDwvpzY for ; Tue, 10 Nov 2015 10:54:18 -0800 (PST) Received: from mail1.trendhosting.net (mail1.trendhosting.net [IPv6:2001:67c:1388:1000::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0811F1B3CCD for ; Tue, 10 Nov 2015 10:54:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail1.trendhosting.net (Postfix) with ESMTP id 8A793150D1 for ; Tue, 10 Nov 2015 18:54:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pocock.pro; s=mail; t=1447181655; bh=A17OJe7zYfK4JWCix8TI5Mz21rHA0TIzSlJNri8zIiM=; h=Date:From:To:Subject:From; b=YKb3hbw3OfFBPDOGvtKGBN+Lhus7WqlX/aygCLRIgfzR5gagryzasN7JMnmzKpEKN 1YzI/9PJyZ+eljb0jy49ivh3MPmTZMr2MeUOdIuFOCzd1Z0ghsYCSE/TwVLPBPzZKA Bf5gMJJxIz8WM1gSvBBnRbXHu3HhbbalZd3c7d5E= Received: from mail1.trendhosting.net ([127.0.0.1]) by localhost (thp003.trendhosting.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZVyUQAtWSVcU for ; Tue, 10 Nov 2015 18:54:12 +0000 (GMT) Message-ID: <56423D53.3080507@pocock.pro> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pocock.pro; s=mail; t=1447181652; bh=A17OJe7zYfK4JWCix8TI5Mz21rHA0TIzSlJNri8zIiM=; h=Date:From:To:Subject:From; b=VlBKJdVpaD8ptNn5bIOT7aUYATuj8/IxmStEZVDk0EOrdVZlKlJoIqwf0359FO6eS RXan1PN5qYIRSiGq2Mu/ifwmZuJTf27s5yIyJIxPOnYm7nT891IPBTg9DIjw69Z4S6 /mqvedVQVuIpD0dJ6uUGydPcs6lD8KPwHhuVYXQM= Date: Tue, 10 Nov 2015 19:54:11 +0100 From: Daniel Pocock User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: tram@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] TURN over TLS / Certificate CN? 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, 10 Nov 2015 18:54:20 -0000 I've seen various RFCs describing the URIs[1] and NAPTRs[2] for TURN One thing that is not clear to me from reading them is the common name (CN) or subjectAltName that should be in the certificate on the server and how the client should decide whether to trust that name. Could anybody comment on this or suggest what I should read? Can anybody comment on how clients like Chrome WebRTC and ice4j are behaving in practice? 1. https://tools.ietf.org/html/rfc7065 2. https://tools.ietf.org/html/rfc5928 From nobody Tue Nov 10 13: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 BD14A1A90C4 for ; Tue, 10 Nov 2015 13:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 a-u7iLDNvr22 for ; Tue, 10 Nov 2015 13:33:04 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id DA0721A90B0 for ; Tue, 10 Nov 2015 13:33:00 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8B5E2423FD1 for ; Tue, 10 Nov 2015 21:33:00 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 75960423F74 for ; Tue, 10 Nov 2015 21:33:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447191180; bh=EWCcKtsgEW0gtqhBI96MwAhSH/8hFpbdlXgYfb7W5/w=; l=1978; h=To:References:From:Date:In-Reply-To:From; b=zi6E/PWeQDJPiXxobkbZ+O/uawL/fiGVq2K1Zbe9XjsQEr/KJnUqC6F5f7OWamdm+ +tO5xCkOoDigq1WCj95kovsj4a7kdbpZFLEmkHGaJPDs51YrOPrvQ9YTlwu6kOsFYY h55eCN8lx9TYGxPbBh7AA3Wcm+TGvRlmJlM3d9Wo= Received: from [172.28.113.245] (bowill.kendall.corp.akamai.com [172.28.113.245]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 505D5214E for ; Tue, 10 Nov 2015 21:33:00 +0000 (GMT) To: "tram@ietf.org" References: <56426125.20204@akamai.com> From: Brandon Williams Message-ID: <5642628C.2050400@akamai.com> Date: Tue, 10 Nov 2015 16:33:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56426125.20204@akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] draft-ietf-tram-stun-origin-06.txt review X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 21:33:05 -0000 Here's the review that I promised to write up. Sorry I didn't get it out before the meeting. I already raised my biggest concerns in the meeting last week, but will repeat them for the list: * Although I understand the privacy concerns that have been raised, I think that the new "Origin Matching Rules" makes the attribute enough less useful that I likely would not implement support. We do some fairly unique things for client-specific relay mapping, so I understand if I'm in the minority on this point, and I don't consider the draft bad to publish if there are enough others who still consider it useful with this limitation. * I am concerned that some of the suggested uses for the attribute provide an incentive to lie. I'm not convinced by the argument that the system won't work if you lie, because there is no requirement to use ORIGIN as a realm selector for auth purposes. As a result, the client could lie in order to get through a related firewall restriction or to get around a service limitation on the relay. OK, as for the minor comments ... S2.2 The new text requires the client to send ORIGIN in any case that matches the constraints in S2.1. The old text only required it for web origins and only recommended it for others. What's the reason for the change? The section would benefit from a rationale for the MUST. S2.3 The same comment about changed requirements and providing a rationale applies. S4 This probably should have occurred to me in earlier reviews, but I now see that the Security Considerations section conflicts with the requirements text in S2.2 and S2.3. The earlier sections require ORIGIN to be sent in some messages where Security Considerations directly allows it to be omitted if not using (D)TLS. It's a little confusing for it to be expressed as required in one place and not required in another. That's it. Please let me know if you have any questions about the above. --Brandon From nobody Thu Nov 19 09:20:53 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 823EE1B2DE6 for ; Thu, 19 Nov 2015 09:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gQbG7OVIuOu for ; Thu, 19 Nov 2015 09:20:35 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 A1B711B2DAE for ; Thu, 19 Nov 2015 09:20:34 -0800 (PST) Received: by ioir85 with SMTP id r85so96319009ioi.1 for ; Thu, 19 Nov 2015 09:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RXIO8dzgjei+0B2UpCbvhI3XIsVVXpAagpgTvn9lNYE=; b=YwsGaMoNSuXX+gsFky9sIKMDab8v6IjC2xZ1pVPtKBCbm6+1eJ6E6Riwyu2g4tGBPy R+czP2L7+IuaC+Sw+4qNXBHDKVUnoqoBfIFGbIk6TDltozpxch3KA/fNqAmFPx4fffvy 1Mg6IFFnQ8ZS2qKYzcwJPXDOwshnYOKZNqZDWEonFGWfizE5K1wcwd9spXCwh65/STY5 z4oFFd0FxPiXIZfm4/QCSrdhrp7vu2Lqhtpz6PgpUtnSmznvju87IPzD4o6VNbQbZjKD x43+Tqd27IhQCJv7Yjsv+vLna4hBEukF846pSVnym//Jv+Vxxe8M+7abvIEG08+2wGA6 pPsQ== MIME-Version: 1.0 X-Received: by 10.107.11.166 with SMTP id 38mr9811771iol.186.1447953633812; Thu, 19 Nov 2015 09:20:33 -0800 (PST) Received: by 10.79.33.137 with HTTP; Thu, 19 Nov 2015 09:20:33 -0800 (PST) In-Reply-To: <5642628C.2050400@akamai.com> References: <56426125.20204@akamai.com> <5642628C.2050400@akamai.com> Date: Thu, 19 Nov 2015 11:20:33 -0600 Message-ID: From: Alan Johnston To: Brandon Williams Content-Type: multipart/alternative; boundary=001a113ed818feaa860524e7f9be Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-stun-origin-06.txt review X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 17:20:43 -0000 --001a113ed818feaa860524e7f9be Content-Type: text/plain; charset=UTF-8 Brandon, Thanks for sending your comments to the list. We'll get answers to you soon, along with some discussion about the HOST alternative that has been raised. - Alan - On Tue, Nov 10, 2015 at 3:33 PM, Brandon Williams < brandon.williams@akamai.com> wrote: > Here's the review that I promised to write up. Sorry I didn't get it out > before the meeting. > > I already raised my biggest concerns in the meeting last week, but will > repeat them for the list: > > * Although I understand the privacy concerns that have been raised, I > think that the new "Origin Matching Rules" makes the attribute enough > less useful that I likely would not implement support. We do some fairly > unique things for client-specific relay mapping, so I understand if I'm > in the minority on this point, and I don't consider the draft bad to > publish if there are enough others who still consider it useful with > this limitation. > > * I am concerned that some of the suggested uses for the attribute > provide an incentive to lie. I'm not convinced by the argument that the > system won't work if you lie, because there is no requirement to use > ORIGIN as a realm selector for auth purposes. As a result, the client > could lie in order to get through a related firewall restriction or to > get around a service limitation on the relay. > > OK, as for the minor comments ... > > S2.2 The new text requires the client to send ORIGIN in any case that > matches the constraints in S2.1. The old text only required it for web > origins and only recommended it for others. What's the reason for the > change? The section would benefit from a rationale for the MUST. > > S2.3 The same comment about changed requirements and providing a > rationale applies. > > S4 This probably should have occurred to me in earlier reviews, but I > now see that the Security Considerations section conflicts with the > requirements text in S2.2 and S2.3. The earlier sections require ORIGIN > to be sent in some messages where Security Considerations directly > allows it to be omitted if not using (D)TLS. It's a little confusing for > it to be expressed as required in one place and not required in another. > > > That's it. Please let me know if you have any questions about the above. > > --Brandon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113ed818feaa860524e7f9be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brandon,

Thanks for sending your commen= ts to the list.=C2=A0 We'll get answers to you soon, along with some di= scussion about the HOST alternative that has been raised.

- Alan -

On Tue, Nov 10, 2015 at 3:33 PM, Brandon Williams <br= andon.williams@akamai.com> wrote:
Here's the review that I promised to write up. Sorry I didn'= t get it out
before the meeting.

I already raised my biggest concerns in the meeting last week, but will
repeat them for the list:

* Although I understand the privacy concerns that have been raised, I
think that the new "Origin Matching Rules" makes the attribute en= ough
less useful that I likely would not implement support. We do some fairly unique things for client-specific relay mapping, so I understand if I'm=
in the minority on this point, and I don't consider the draft bad to publish if there are enough others who still consider it useful with
this limitation.

* I am concerned that some of the suggested uses for the attribute
provide an incentive to lie. I'm not convinced by the argument that the=
system won't work if you lie, because there is no requirement to use ORIGIN as a realm selector for auth purposes. As a result, the client
could lie in order to get through a related firewall restriction or to
get around a service limitation on the relay.

OK, as for the minor comments ...

S2.2 The new text requires the client to send ORIGIN in any case that
matches the constraints in S2.1. The old text only required it for web
origins and only recommended it for others. What's the reason for the change? The section would benefit from a rationale for the MUST.

S2.3 The same comment about changed requirements and providing a
rationale applies.

S4 This probably should have occurred to me in earlier reviews, but I
now see that the Security Considerations section conflicts with the
requirements text in S2.2 and S2.3. The earlier sections require ORIGIN
to be sent in some messages where Security Considerations directly
allows it to be omitted if not using (D)TLS. It's a little confusing fo= r
it to be expressed as required in one place and not required in another.

That's it. Please let me know if you have any questions about the above= .

--Brandon

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

--001a113ed818feaa860524e7f9be--