Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25

Benjamin Kaduk <kaduk@mit.edu> Wed, 26 June 2019 13:37 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AB5120044; Wed, 26 Jun 2019 06:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yQWfbc7CBU2R; Wed, 26 Jun 2019 06:37:46 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B4593120075; Wed, 26 Jun 2019 06:37:46 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5QDbaGo007305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Jun 2019 09:37:39 -0400
Date: Wed, 26 Jun 2019 08:37:36 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "touch@strayalpha.com" <touch@strayalpha.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-tram-turnbis.all@ietf.org" <draft-ietf-tram-turnbis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "brandon.williams@akamai.com" <brandon.williams@akamai.com>, "tram@ietf.org" <tram@ietf.org>
Message-ID: <20190626133736.GA18345@kduck.mit.edu>
References: <edcd66c2-0dfb-8f89-d6a3-53482c433d4e@strayalpha.com> <DM5PR16MB17057CCD4D2543D84254EFD1EAEB0@DM5PR16MB1705.namprd16.prod.outlook.com> <HE1PR0701MB2522DCB2459055A6319C439B95EA0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <DM5PR16MB1705E3EF8260B456A9B02C10EAEA0@DM5PR16MB1705.namprd16.prod.outlook.com> <HE1PR0701MB2522C0A1063877D45985619795EA0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <BD41AC2D-3925-4E11-B1EC-AD24680376AE@strayalpha.com> <DM5PR16MB1705F636477B6234FEA35A04EAE50@DM5PR16MB1705.namprd16.prod.outlook.com> <20190624233637.GF48838@kduck.mit.edu> <HE1PR0701MB25224C8F0585C940B8DBFFF695E30@HE1PR0701MB2522.eurprd07.prod.outlook.com> <DM5PR16MB17058A3EEC90267BA9A6458DEAE20@DM5PR16MB1705.namprd16.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DM5PR16MB17058A3EEC90267BA9A6458DEAE20@DM5PR16MB1705.namprd16.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/X7x8uwZsr_Tq_0oCQCfymKBvWR8>
Subject: Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
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." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2019 13:37:48 -0000

On Wed, Jun 26, 2019 at 10:32:48AM +0000, Konda, Tirumaleswar Reddy wrote:
> As per the suggestion from Magnus, modified text as follows:
> 
> TCP connection between the TURN client and server can use TCP-AO [RFC5925] but UDP does not provide a similar type of authentication until UDP supports
> authentication option.  If TCP-AO would be used between TURN client and server, it would not change the end-to-end security properties of
> the UDP payload being relayed.  Therefore applications using TURN will need to secure their application data end-to-end appropriately, e.g.  SRTP for RTP applications.  

That looks better; thanks!  (And thanks to Magnus for noticing!)

-Ben