Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Sat, 13 July 2019 06:34 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.com>
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 ACEC21200BA for <tram@ietfa.amsl.com>; Fri, 12 Jul 2019 23:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com
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 uzDPjFTIDcwY for <tram@ietfa.amsl.com>; Fri, 12 Jul 2019 23:34:20 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E2112008F for <tram@ietf.org>; Fri, 12 Jul 2019 23:34:19 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562999012; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=HdHIBLUvxV9nBwHx9il9njs1v1KMliJoOD6aSk JnyRs=; b=oK29Fhqcgr7+eWrAvP7JXj6Xdpufr7qxmGOMT3OQ O07Hgg6OBBry7NizRcLGR5insLZKiBGb97pHE0VBoTEJ1bf5hM Y5bWSXHeKuwYRDT90YJ1i6u2f2VjkG1QxTp2XicOKhnxkL7mVh /hvVEAy0sjZ2mP3esZVyWp6i6XtpnkU=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-64-f9efpBi6MVS1ut7ZN3N54A-1; Sat, 13 Jul 2019 02:34:11 -0400
Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6c32_3f4c_f84f959d_71c3_41ce_bc1b_9db7e5c5de58; Sat, 13 Jul 2019 00:23:30 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:34:07 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 13 Jul 2019 00:34:06 -0600
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:34:06 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EXw85X756G8NCkL76pr70n1cFh5ej4kQcFFUXS0d+L5ZOunudwJn09OS8dY6HG6A8KF4mo+HEcsKtItzTEBK7bZJQB0i0qQ5KhwzhWCzKrB+hFn2bO/QngtTmJr2DNkiZLw/LYc4Vr8jVYn53JXBkZKdnkjccuQcj4URuAEJNDLL/I807vFN4vji1MLIeuoKIm9bhMDbTOUFGDoDIt47WDvju/fZAv9uM+DYwKfkhB0ys/CenumcyoI/t0d1nh+noIsX2RDvHkIiI5JyQc2L5NI1LyWYe+WRltS6xVB9oSgO7i2P2qYYJV8be65eLOwnMEUuTAKY31nK3DgecpIKUw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HdHIBLUvxV9nBwHx9il9njs1v1KMliJoOD6aSkJnyRs=; b=EIN+TWcgw3lYylIyNMR5x2FV8XUq+L5k4Vvqp0bgKbv4JwqdCKvR0LgLFeNq/qvXyGr9mgiuenbP7G/qzkZuB6zAHJ1mG9njfI57Nj2hYeO4E+1XlkfD7Y2dlM21LYpY1sfsLd5W1TAvz+5XwhIcIwPZULMu8XcgUWWZZ6heWDUnTQa/IiJXscPRRZxMZ3NuCRt8hRPagjpjHzR2E1dCFsPfO+GbVnd/5eey0CWZADmIis9fRDImaVk3Tz2pW3IkoSf13lzzpp502CcoqCKH+tRl36O9Rp9q/7b36nuZsb2DMybKsCV0Paq+TfW3BUUTjdlDseJ0+sQoLsThW4oPpg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5SPR00MB110.namprd16.prod.outlook.com (10.174.247.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Sat, 13 Jul 2019 06:34:03 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.022; Sat, 13 Jul 2019 06:34:03 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Christopher Wood <caw@heapingbits.net>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-tram-turnbis.all@ietf.org" <draft-ietf-tram-turnbis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBwgAJPmICAAKIlAIAEbccAgABJSTA=
Date: Sat, 13 Jul 2019 06:34:03 +0000
Message-ID: <DM5PR16MB1705CA7A7BA6D7F7706B1D5AEACD0@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <DM5PR16MB17057A838828AE1DFD33702AEAF60@DM5PR16MB1705.namprd16.prod.outlook.com> <20190709203044.GD24351@kduck.mit.edu> <DM5PR16MB17055A8B96B74CD7E978591FEAF00@DM5PR16MB1705.namprd16.prod.outlook.com> <20190713014901.GQ16418@mit.edu>
In-Reply-To: <20190713014901.GQ16418@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.16
dlp-reaction: no-action
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 283f07b6-b761-4696-6c1b-08d7075c1936
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5SPR00MB110;
x-ms-traffictypediagnostic: DM5SPR00MB110:
x-ms-exchange-purlcount: 10
x-microsoft-antispam-prvs: <DM5SPR00MB110C04B379C32E91D158AF0EACD0@DM5SPR00MB110.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00979FCB3A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(13464003)(32952001)(199004)(189003)(51914003)(6246003)(55016002)(7736002)(2171002)(6306002)(9686003)(305945005)(66066001)(81156014)(81166006)(5024004)(53936002)(53546011)(74316002)(33656002)(256004)(14444005)(54906003)(30864003)(478600001)(3846002)(476003)(486006)(102836004)(6506007)(25786009)(99286004)(7696005)(8936002)(11346002)(6116002)(76176011)(2906002)(5660300002)(6436002)(68736007)(66946007)(229853002)(316002)(86362001)(52536014)(8676002)(186003)(80792005)(4326008)(446003)(6916009)(966005)(66556008)(66446008)(76116006)(71200400001)(71190400001)(64756008)(66476007)(14454004)(26005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5SPR00MB110; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: fP6KleNox3jXAqkgTODruftalyd/njDKzBh9tSWHLoUWm+Hbu92F5BcyBQ704zg3R58t+5e748r51E60Esq4O3khvmhh40+hqbH9PlPmSGz9U94Zpj3o6TiWD43wUYGTk5QWmLo/IDWIuuLXwevOg8WZdnPlGt6xLGGZ0l21KN4t5LrS7Q0FFX9GwgYkhVbiRyLKyTMEt8F75LVF/4UDOHDzn2vGJBlU1RJw4PDOt0miRLEOe0f3w5EJmdAqxuBRuQrl3GpF5ESs6oaUS5PgKmTxs2wTi9C5WrqHpnN9rpPnYEtgMP4hEhIlh8krO8uwlpBL5JWWDryd9WNgNbe/RdSAYRudPcWx0/gSfC1O1gJvzTuXsArUMij7SJ/oHHfl4bu6kRPjx59xDQCF1z4uDBx1dhZ7FkEsTzLFfhw44n4=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 283f07b6-b761-4696-6c1b-08d7075c1936
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2019 06:34:03.5795 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5SPR00MB110
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7119> : streams <1827208> : uri <2867009>
X-MC-Unique: f9efpBi6MVS1ut7ZN3N54A-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/wCNJhM7BtMYzsO7JdqqCHRxNw4U>
Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
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: Sat, 13 Jul 2019 06:34:26 -0000

Hi Ben,

Please see inline

> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>;
> Sent: Saturday, July 13, 2019 7:19 AM
> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
> Cc: Christopher Wood <caw@heapingbits.net>;; secdir@ietf.org; draft-ietf-
> tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org
> Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Tiru,
> 
> Thanks for all the updates, including further downthread with Chris.
> Just a couple notes inline...
> 
> On Wed, Jul 10, 2019 at 12:40:37PM +0000, Konda, Tirumaleswar Reddy wrote:
> > Hi Ben,
> >
> > Thanks for the review. Please see inline.
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk <kaduk@mit.edu>;
> > > Sent: Wednesday, July 10, 2019 2:01 AM
> > > To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>;
> > > Cc: Christopher Wood <caw@heapingbits.net>;; secdir@ietf.org;
> > > draft-ietf- tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org
> > > Subject: Re: [tram] Secdir last call review of
> > > draft-ietf-tram-turnbis-27
> > >
> > > This email originated from outside of the organization. Do not click
> > > links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > >
> > > Chris, thanks for the review.  Some more questions/comments inline
> > > as I prepare to ballot on this document...
> > >
> > > On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy
> wrote:
> > > > Hi Christopher,
> > > >
> > > > Thanks for the detailed review. Please see inline
> > > >
> > > > > -----Original Message-----
> > > > > From: tram <tram-bounces@ietf.org>; On Behalf Of Christopher
> Wood
> > > > > via Datatracker
> > > > > Sent: Monday, July 8, 2019 1:59 AM
> > > > > To: secdir@ietf.org
> > > > > Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org;
> > > > > tram@ietf.org
> > > > > Subject: [tram] Secdir last call review of
> > > > > draft-ietf-tram-turnbis-27
> > > > >
> > > > > This email originated from outside of the organization. Do not
> > > > > click links or open attachments unless you recognize the sender
> > > > > and know the content is safe.
> > > > >
> > > > > Reviewer: Christopher Wood
> > > > > Review result: Has Nits
> > > > >
> > > > > I have reviewed this document as part of the security
> > > > > directorate's ongoing effort to review all IETF documents being
> > > > > processed by the IESG. These comments were written primarily for
> > > > > the benefit of the security area directors.
> > > > > Document editors and WG chairs should treat these comments just
> > > > > like any other last call comments.
> > > > >
> > > > > The summary of the review is: Ready with nits
> > > > >
> > > > > Summary:
> > > > >
> > > > > In general, the document is well written and clearly founded in
> > > > > operational experience. The security considerations are
> > > > > thorough, providing examples where necessary to highlight
> > > > > important problem areas. It draws a clear line between issues
> > > > > best addressed by applications outside of TURN, and provides
> > > > > sufficient detail for those issues in scope. My comments and
> > > > > questions are, hopefully, mostly
> > > nits.
> > > > >
> > > > > General comments:
> > > > >
> > > > > - TURN server authentication in the case of (D)TLS is
> > > > > underspecified. Are servers assumed to have WebPKI certificates,
> > > > > OOB-trusted raw public keys, or something else? Is there a
> > > > > preferred
> > > form of authentication?
> > > > > Relatedly, in
> > > > > Section 3.2, how do clients authenticate the server?
> > > >
> > > > Server certificate validation is discussed in
> > > > https://tools.ietf.org/html/draft-
> > > ietf-tram-stunbis-21#section-6.2.3.  I have modified the text as follows:
> > > >
> > > > If (D)TLS transport is used between the TURN client and the TURN
> > > > server, the cipher suites, server certificate validation and
> > > > authentication of TURN server are discussed in Section 6.2.3 of
> > > > [I-D.ietf-tram-stunbis]
> > >
> > > That helps, but it would still be nice to give some indication of
> > > what certificate
> > > PKI(s) are expected to be used.  Is anything other than the Web PKI
> > > under consideration ?
> >
> > No. Please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-
> 21#section-6.2.3, It discusses to verify the certificate path and identity of the
> server.
> >
> > >
> > > > >- Section 3.7: Could
> > > > > TURN servers not chunk data from stream-oriented transports (TCP
> > > > >or
> > > > >TLS)  to a preferred MTU size before relaying to peers?
> > > > > Specifically, there are likely
> > > > > some cases wherein the server could deal with the client data
> > > > >messages  larger than the recommended 500B limit. On that point,
> > > > >should servers even  accept data larger than this recommended size ?
> > > > >-
> > > >
> > > > Please see
> > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15
> > > > for TCP-to-UDP relay. If the PMTU is not known, and on legacy or
> > > > otherwise unusual networks,
> > > > 500 byte limit for application data is recommended.
> > > >
> > > > > Section 3.9: There may be
> > > > > cases where the TLS connection post TCP connection establishment
> > > > > fails. It would therefore seems prudent to not declare victory
> > > > > for one connection over the other until TLS connects, too. -
> > > >
> > > > Agreed, Eric (as part of ISEG review) suggested to simplify the
> > > > text. I have
> > > updated the text as follows:
> > > >
> > > >    o  For TCP or TLS-over-TCP, the results of the Happy Eyeballs
> > > >       procedure [RFC8305] are used by the TURN client for sending its
> > > >       TURN messages to the server.
> > >
> > > Is the editor's copy available for viewing somewhere?  It would be
> > > good to see this (and other changes) in context.
> >
> > Yes, Please see https://github.com/tireddy2/TURNbis
> >
> > >
> > > > > Section 3 could benefit from a
> > > > > subsection on replays and the nonce role. In particular, as
> > > > > later discussed in the security considerations, some of these
> > > > > attacks are not new to TURN and should therefore be dealt with
> > > > > by the application protocol (SRTP). This section might also
> > > > > describe nonce rotation policies with more specificity, as this
> > > > > is underspecified in the
> > > document.
> > > >
> > > > It is discussed in Section 5 in the specification, the server
> > > > should expire the
> > > nonce at least once every hour during the lifetime of the allocation.
> > > >
> > > > >- Section 3 could also benefit from  discussion about cleartext
> > > > >versus encryption transports between clients and  servers.
> > > >
> > > > It is discussed in
> > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-
> > > 27#section-21.1.6.
> > >
> > > There's not much discussion about potential information  leakage via
> > > (e.g.) USERNAME/USERHASH, and really just a claim that the peer
> > > address is the "primary protocol content".
> >
> > Agreed, added the following paragraph :
> >
> > If the TURN client and server use the STUN Extension for Third-Party
> > Authorization [RFC7635], the username does not reveal the real user's
> identity, the USERNAME attribute carries an ephemeral and unique key
> identifier, and the key identifier can change per call.
> > If the TURN client and server use the STUN long-term credential
> > mechanism and the username reveals the real user's identity, the
> > client need to either use (D)TLS transport between the client and the
> server or use the USERHASH attribute instead of the USERNAME attribute to
> anonynmize the username.
> >
> > >
> > > > > Encrypting the nonce, username, realm, etc., among other things,
> > > > > has obvious benefits. - Why are SOFTWARE and FINGERPRINT
> > > > > attributes recommended?  It seems like clients should be
> > > > > discouraged from sending these if anything, especially if not
> > > > > used to make allocation decisions on the server.
> > > >
> > > > Username may not be the user identity, Please see
> > > https://tools.ietf.org/html/rfc7635), It could be an ephemeral and
> > > unique key identifier. Further, username can be anonymized (please
> > > see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4).
> > > > SOFTWARE and FINGERPRINT attributes are defined in the STUN
> > > specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21.
> > >
> > > These mechanisms  are partial mitigations but can still be
> > > susceptible to cross- connection correlation attacks.
> >
> > The use of FINGERPRINT is not mandatory, the TURN client and server may
> include the FINGERPRINT attribute.  Note that ICE
> (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT
> attribute. Added the following line for SOFTWARE attribute (TURNbis is using
> the same behavior defined in RFC5766 to use SOFTWARE attribute)  :
> >
> > SOFWATE attribute can reveal the specific software version of the TURN
> client and server to eavesdropper and it might possibly allow attacks against
> vulnerable software that is known to contain security holes. If it is important
> to prevent an eavesdropper from learning the software version, TURN can
> be run over (D)TLS.
> 
> The later suggestion was:
> 
> % We want to avoid double encryption of application data, and SOFTWARE
> attribute has
> % been sent in clear text all these years in the field, and no attack has been
> % detected based on SOFTWARE field. I can revise the text as follows:
> % If the software version is known to contain security vulnerabilities, TURN
> SHOULD be % run over (D)TLS to prevent leaking the SOFTWARE attribute in
> clear text.
> 
> I think some of the concern is over the risk of so-called "zero-day"
> exploits, where the attacker knows of a version-specific flaw but the
> defenders do not (and have zero days notice to protect against it).  Such a
> concern would suggest to avoid sending SOFTWARE over enencrypted
> transport regardless of the state of known vulnerabilities, but in the end it is
> a matter of local policy.

Agreed, fixing and releasing a patch will take some time and meanwhile the policy can be modified to use temporarily use (D)TLS.  I can add the following text:
If zero-day vulnerabilities are detected in the software version, the endpoint policy can be modified to mandate the use of (D)TLS till the patch is in place to fix the flaw.

> 
> 
> >
> > >
> > > > - Section 5: When servers receive data that exceeds an
> > > > allocation’s
> > > > > bandwidth quota, servers silently discard this data. This means
> > > > > there’s no allocation-based flow control mechanism between
> > > > > client and server beyond what’s provided by the transport protocol,
> right?
> > > >
> > > > Yes, UDP does not include a congestion control mechanism.
> > > >
> > > > > This seems fine, though
> > > > > perhaps some discussion of why this design decision was made
> > > > > would be helpful. For example, I could imagine explicit signals
> > > > > from servers to clients that indicate server state would reveal
> > > > > information about other allocations on the server, which might
> > > > > be problematic. -
> > > >
> > > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient
> > > > Capacity)
> > > do not reveal information of which other users are using the TURN server.
> > >
> > > At least the latter seems to give some indication that many other
> > > users are using the server at the  time (so that it's overloaded),
> > > though not information about *which* users that is.
> >
> > Yes, similar to 503 HTTP error response.
> >
> > >
> > > > > Section 7.2 suggests that
> > > > > servers can redirect client allocation requests to other servers.
> > > > > Can this create a loop, wherein two TURN servers redirect to one
> another?
> > > >
> > > > The client detect and stop the loop, it is similar to HTTP redirection.
> > >
> > > Where is this specified?
> >
> > It is specified in the last paragraph of
> > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10
> >
> > <snip>
> > If the client has been redirected to a server to which it has already
> > sent this request within the last five minutes, it MUST ignore the
> > redirection and consider the transaction to have failed.  This
> > prevents infinite ping-ponging between servers in case of redirection
> > loops.
> > </snip>
> 
> Thanks for the pointer; as you saw in my ballot position I was quite pressed
> for time this week and only was able to look at the diff.

No problem, thanks for help.

Cheers,
-Tiru

> 
> -Ben