Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Wed, 17 July 2019 12:50 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 2F7C812004D for <tram@ietfa.amsl.com>; Wed, 17 Jul 2019 05:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 v5SK2or1674R for <tram@ietfa.amsl.com>; Wed, 17 Jul 2019 05:50:07 -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 6A2BD1200DE for <tram@ietf.org>; Wed, 17 Jul 2019 05:50:07 -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=1563366232; 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=XIxL5PXtTOv2leRRPTqjKq/M6bwawwaTmcqg67 7UgYY=; b=Vt83B0iccUu7wvE9j+cLvNnvdCttIdxzNFhcmiQ0 gRfori/Jm/mulVuIykzS/bA6JayOMbPa9R12B9oy5Vpi/ZDekN peU2CPX15L21ZVhhfJNuuLgVqhLrRDEv09AfgGOiTGioQT3R0l A70zmF4Zp45J2wKlxT826QjPOWPjCK0=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-244-mOPfTrtiMN2k953TwVTrMw-1; Wed, 17 Jul 2019 08:34:48 -0400
Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6bf8_4068_b5c46a7b_3fa2_45d2_8941_56e794881cb7; Wed, 17 Jul 2019 06:23:51 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Jul 2019 06:34:43 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 17 Jul 2019 06:34:43 -0600
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Jul 2019 06:34:41 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RjJQJdTldhstoFjEAICM6W28s7QBkj1N3p3YYuqKQuRNpjcapC3QlTJo1YvdgUqycJSNoD5RO8DChq+dZx9smjgb+9zb1yfpMmoX/bj43n6n1j1hqBUE61LHhjS4KEVDmJ6dPqsihJWbuKy3RUXOGW5QnYCSiu7/1nT5t9lE/wXXqn8m/gbuXy2cEBDreke9qYM5QFYRVLB4z3AehiSudB+ZYeADm0foyf1mf9dOpb3RiqDSc2DLprYN+e2atrzqJg1N9xFs2WXiYjWmYi5nuSPSwdkmvadxz55SG/qBcenU52D8T0rXCUoui4KwYdBOs6Q2J0FkRcMLzYdRAST9iA==
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=XIxL5PXtTOv2leRRPTqjKq/M6bwawwaTmcqg677UgYY=; b=VoDxI+LhC110nEecbe8l7d/FU5jcbSxRCTUCw/CqhtCZPF1YfuG1keHn56lQuyD/twNvu6sQXOLN4slGVg9w73/dxg9naWBnK7aI54qJFyTQXuJCh4zlpLM2n+1VtDRs3dJGHROWaqSR5yVbzhqa0ubYrt6ru1uuhfgVNPqe8utyEIBjufLouAzek8PuDg6J3C0HEUUkSt9kMzlgLMev8/+B9oMTF9tE0AJWLy3td0tAhiv+sI7ba7SLaIWDwizRNd3XQxEIk6UAEuq0lAnZ0P+Uf08fqNxUMnRZvlFR8OuAdGZSlWibYYEQf9rrV/jEVLTVv9kUKUiRRRwpzxs4pA==
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 DM5PR16MB1578.namprd16.prod.outlook.com (10.173.211.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Wed, 17 Jul 2019 12:34:41 +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.2073.012; Wed, 17 Jul 2019 12:34:41 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "draft-ietf-tram-turnbis@ietf.org" <draft-ietf-tram-turnbis@ietf.org>, "tram@ietf.org" <tram@ietf.org>, "brandon.williams@akamai.com" <brandon.williams@akamai.com>
Thread-Topic: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
Thread-Index: AQHVN6sj5hqeZIdQXEa8/G2g6Mwv66bFIQEggAKxEACAAC4dEIAGk5Ww
Date: Wed, 17 Jul 2019 12:34:41 +0000
Message-ID: <DM5PR16MB17051565AEE4F1C6A269F275EAC90@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com> <DM5PR16MB170591028C0B2CF13325137CEAF30@DM5PR16MB1705.namprd16.prod.outlook.com> <20190713021429.GR16418@mit.edu> <DM5PR16MB17052EB2FF35DBA258F5CC03EACD0@DM5PR16MB1705.namprd16.prod.outlook.com>
In-Reply-To: <DM5PR16MB17052EB2FF35DBA258F5CC03EACD0@DM5PR16MB1705.namprd16.prod.outlook.com>
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: 19eddaa3-fa7b-4970-f725-08d70ab323fd
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1578;
x-ms-traffictypediagnostic: DM5PR16MB1578:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <DM5PR16MB1578CF806FD5354D4E4C25EFEAC90@DM5PR16MB1578.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01018CB5B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(39860400002)(396003)(136003)(32952001)(199004)(189003)(51914003)(54094003)(13464003)(71190400001)(80792005)(186003)(305945005)(52536014)(71200400001)(229853002)(4326008)(3846002)(33656002)(7736002)(6116002)(25786009)(11346002)(476003)(478600001)(30864003)(966005)(74316002)(446003)(5660300002)(256004)(5024004)(14444005)(2906002)(81156014)(8936002)(81166006)(14454004)(9686003)(6306002)(7696005)(53946003)(6916009)(68736007)(66066001)(55016002)(6436002)(54906003)(86362001)(26005)(2171002)(6506007)(53546011)(102836004)(6246003)(8676002)(99286004)(486006)(66556008)(76116006)(316002)(53936002)(64756008)(66476007)(66946007)(76176011)(66446008)(85282002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1578; 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: PJMPIt6y1geM0UnlsSbF11YnoxKwIgmLHK9TqeTVdYFspEU2wbM1e5NUX7J3okvwDGH76N5fY7lTjp/2MH2QxoMtneC3XyR20LC/VI0Vr2Oz7Ns4jo48wMiSzfwm2fJCE091nWwHvUtTHFzg1/rT3QBvRuJGJ9yEArJkM9jVOLUIOPCbQ6K9sf+pkekR3bZ5B9RWgr+Z0lPCO+TcHs3Duq7ewGL3Iv4UGcRZNwa1GVJN9ngsEu/Q7S2sLp5yLhjkAhN6aerTCLoyggeT7vm7H1MK7d0eQrSLY2N/bDNEze/NrmTlBFbNuVNpUvz6ZtuU1aceurM1uVFV+ggaRNtI8Cev20jbqZISaHsuMO6Y+0A5VZnqHQc93NLVq2EjPxD5CrAOg8v/UorSmdyX6cf8kfSzX9YmtRtqF9kcQ++IU/k=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 19eddaa3-fa7b-4970-f725-08d70ab323fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 12:34:41.4784 (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: DM5PR16MB1578
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.3
X-NAI-Spam-Version: 2.3.0.9418 : core <6591> : inlines <7120> : streams <1827614> : uri <2868588>
X-MC-Unique: mOPfTrtiMN2k953TwVTrMw-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/Kt23noV3LyzyoesRg3XYgTY5yl4>
Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
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, 17 Jul 2019 12:50:11 -0000

Hi Ben,

I have updated the draft to address your Discuss and comments in both Secdir thread and this one (Please see https://github.com/tireddy2/TURNbis/blob/master/Diff%20%20draft-ietf-tram-turnbis-27.txt%20-%20draft-ietf-tram-turnbis-28.pdf). Please review.
 
Cheers,
-Tiru

> -----Original Message-----
> From: Konda, Tirumaleswar Reddy
> Sent: Saturday, July 13, 2019 11:41 AM
> To: Benjamin Kaduk <kaduk@mit.edu>;
> Cc: The IESG <iesg@ietf.org>;; tram-chairs@ietf.org; draft-ietf-tram-
> turnbis@ietf.org; tram@ietf.org; brandon.williams@akamai.com
> Subject: RE: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27:
> (with DISCUSS and COMMENT)
> 
> Hi Ben,
> 
> Please see inline
> 
> > -----Original Message-----
> > From: Benjamin Kaduk <kaduk@mit.edu>;
> > Sent: Saturday, July 13, 2019 7:45 AM
> > To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>;
> > Cc: The IESG <iesg@ietf.org>;; tram-chairs@ietf.org; draft-ietf-tram-
> > turnbis@ietf.org; tram@ietf.org; brandon.williams@akamai.com
> > Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27:
> > (with DISCUSS and COMMENT)
> >
> > 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,
> >
> > On Thu, Jul 11, 2019 at 03:47:19PM +0000, Konda, Tirumaleswar Reddy
> wrote:
> > > Hi Ben,
> > >
> > > Thanks for the detailed review. Please see inline
> >
> > Sorry to have made you deduplicate with the reviews that had already
> > come in -- I wrote this text fairly early (on just the diff) with
> > intent to return and tidy up, but ran out of time and had to just submit
> what I had.
> 
> No problem, the review helped to improve the draft.
> 
> >
> > > > -----Original Message-----
> > > > From: tram <tram-bounces@ietf.org>; On Behalf Of Benjamin Kaduk via
> > > > Datatracker
> > > > Sent: Thursday, July 11, 2019 11:10 AM
> > > > To: The IESG <iesg@ietf.org>;
> > > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org;
> > > > tram@ietf.org; brandon.williams@akamai.com
> > > > Subject: [tram] Benjamin Kaduk's Discuss on
> > > > draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
> > > >
> > > >
> > > >
> > > > Benjamin Kaduk has entered the following ballot position for
> > > > draft-ietf-tram-turnbis-27: Discuss
> > > >
> > > > When responding, please keep the subject line intact and reply to
> > > > all email addresses included in the To and CC lines. (Feel free to
> > > > cut this introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to
> > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > --
> > > > DISCUSS:
> > > > ------------------------------------------------------------------
> > > > --
> > > > --
> > > >
> > > > I support Roman's Discuss.
> > >
> > > I have updated the draft to address Roman's Discuss.
> > >
> > > >
> > > > I think I'm confused about whether REQUESTED-ADDRESS-FAMILY and
> > > > ADDITIONAL-ADDRESS-FAMILY are mutually exclusive.
> > >
> > > Yes, both attributes are mutually exclusive. It is discussed in
> > > Section 7.1,
> > Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
> > ADDRESS-FAMILY attributes in the same request.
> >
> > Okay.  This seems weird to  me and I wouldn't object if some very
> > blunt text was added early on about "when both IPv4 and IPv6 are
> > desired, the ADDITIONAL-ADDRESS-FAMILY attribute alone serves to
> > request both address types; otherwise the single
> > REQUESTED-ADDRESS-FAMILY attribute suffices", but this point clearly is
> not Discuss-worthy.
> 
> This point is already covered in Section 5 (General Behavior) as follows:
> 
> TURN, as defined in this specification, supports both IPv4 and IPv6. IPv6
> support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4
> relaying. The REQUESTED-ADDRESS-FAMILY attribute allows a client to
> explicitly request the address type the TURN server will allocate (e.g., an
> IPv4-only node may request the TURN server to allocate an IPv6 address).
> The ADDITIONAL-ADDRESS-FAMILY attribute allows a client to request the
> server to allocate one IPv4 and one IPv6 relay address in a single Allocate
> request. This saves local ports on the client and reduces the number of
> messages sent between the client and the TURN server.
> 
> >
> > > > Does sending just the
> > > > "additional" one secretly mean that you want both v4 and v6?
> > >
> > > Yes, ADDITIONAL-ADDRESS-FAMILY is used for allocation of both IPv4
> > > and
> > IPv6.
> > >
> > > >
> > > > Section 5
> > > >
> > > > I see that the secdir reviewer asked about why it is a "SHOULD" to
> > > > send SOFTWARE, and only got a response that it is defined in
> > > > stunbis, but not about why it is recommended.  There remain some
> > > > privacy/security considerations with it, and we should either
> > > > point to the stunbis security considerations or not recommend using it.
> > > > (FINGERPRINT is, IIRC, less interesting from a security
> > > > perspective as it's just about confirming that given traffic is in
> > > > fact STUN and not something else.)
> > >
> > > This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As
> > > you
> > may know, TURN is used in the field for several years) and turnbis
> > does not modify the behavior for backward compatibility, and to
> > address the possible threat added the following lines:
> > >
> > > SOFTWARE 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.
> >
> > (let's keep this on the secdir thread)
> 
> Okay.
> 
> >
> > > >
> > > > Section 12
> > > >
> > > > Do we need to say anything about backwards compatibility with RFC
> > > > 5766 peers that use a wider range of channel IDs?
> > >
> > > Yes, added the following line:
> > > Note that the channel number range is not backwards compatible with
> > > [RFC5766], and cannot be used in environments where such
> > > compatibility is required.
> >
> > I see now that Adam also raised this topic, and I'd like to hear his
> > thoughts on this proposed text.  Since we normally don't make breaking
> changes in "bis"
> > documents, I'd also like to hear a bit more about what knoweldge we
> > have (if
> > any) about implementations that might be affected and are not affected.
> 
> Update to the TURN channel number range is done in
> https://tools.ietf.org/html/rfc7983#section-9.3 to distinguish multiplexed
> protocols, and the range is updated in turnbis to align with RFC7983 .
> 
> >
> > > >
> > > > Section 12.7
> > > >
> > > >    When the server receives an ICMP packet, the server processes it as
> > > >    described in Section 11.5.  A Data indication MUST be sent regardless
> > > >    of whether there is a channel bound to the peer that was the
> > > >    destination of the UDP datagram that triggered the reception of the
> > > >    ICMP packet.
> > > >
> > > > This MUST seems potentially in conflict with the previous
> > > > discussion about permissions checks in Section 11.5.
> > >
> > > Good catch, removed conflicting text from Section 12.7.
> > >
> > > >
> > > > Section 20
> > > >
> > > > Looking at the
> > > > new nonce in the example ("obMatJos2AAABadl7W7PeDU4hKE72jda"),
> > and
> > > > noting that it starts with the nonce cookie, help me decode the
> > > > security feature bits.  The magic prefix is "obMatJos2" so the
> > > > capability bits are encoded as "AAAB", which decodes to (hex) 00
> > > > 00 01.  But stunbis says that the bits are ordered from 0 (MSB of
> > > > first
> > > > byte) to 23 (LSB of last byte), so this would have bit 23 set,
> > > > which is in contrast to the registry marking bit 0 as the
> > > > password-algorithms
> > feature.  Where am I messing this up?
> > >
> > > You are right, replaced with "obMatJos2gAAAadl7W7PeDU4hKE72jda"
> > > (hex)
> > > 80 00 00
> >
> > It's reassuring to know that I wasn't missing something obvious; thanks!
> 
> Thanks for catching it :)
> 
> >
> > > >
> > > > I'd prefer if the examples showed more usage of MESSAGE-INTEGRITY-
> > > > SHA256 (especially, any from the server) and fewer MESSAGE-
> INTEGRITY.
> > >
> > > Sure, updated examples.
> > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > --
> > > > COMMENT:
> > > > ------------------------------------------------------------------
> > > > --
> > > > --
> > > >
> > > > Thanks for keeping the diff from RFC 5766 relatively contained!
> > > > I only reviewed the diff due to time constraints, but in general
> > > > support reviewing the full document for internal consistency and
> > > > any remarks that have not aged well, especially with respect to
> > > > IANA
> > considerations.
> > > >
> > > > Section 2
> > > >
> > > > RFC 8174 has an updated version of the BCP 14 boilerplate text.
> > >
> > > Fixed.
> > >
> > > >
> > > > Section 3.1
> > > >
> > > > I appreciate the response to the secdir review, but even the
> > > > linked stunbis section does not say much about which PKI's trust
> > > > root is expected to be used.  I'm forced to assume the Web PKI but
> > > > don't have much grounds for that assumption.
> > >
> > > Yes, use pre-populated trust store on the endpoint to validate the
> > certificate path.
> > >
> > > >
> > > > Section 3.2
> > > >
> > > > The secdir reviewer's comments seem to have some relevance.
> > > > It seems like even when the third-party authorization mechanism is
> > > > used, the client is still limited to "the server is authenticated
> > > > because it gives me the service I asked for", which is not really
> > > > documented anywhere yet.  The long-term password mechanism at
> > > > least generates an HMAC integrity tag on messages from server to
> > > > client, which can provide some level of authentication via key
> confirmation.
> > >
> > > No, STURN third-party authorization provides message integrity for
> > > both
> > request and response messages (please see
> > https://tools.ietf.org/html/rfc7635#section-5).  The mac_key to
> > compute the message integrity can change per call and this mechanism
> > is better than the long-term password mechanism. Note that WebRTC uses
> > third-party authorization mechanism.
> >
> > Ah, that's reassuring to learn.  Sorry for the confusion.
> >
> > > >
> > > > Section  3.7
> > > >
> > > >                                        If the TURN server carrying out
> > > >    packet translation from IPv4-to-IPv6 cannot get the Don't Fragment
> > > >    (DF) bit in the IPv4 header, it MUST reject the Allocate request with
> > > >    DONT-FRAGMENT attribute.
> > > >
> > > > nit: does "cannot get" mean something like "read the value as sent
> > > > on the wire" (e.g., due to implementation/API limitations)?
> > >
> > > Yes, cannot read the value as sent on wire.
> >
> > I'd  suggest "is unable to access the state of", but that's entirely
> > editorial and at your discretion.
> 
> Thanks, updated.
> 
> >
> > > >
> > > > Section 6
> > > >
> > > >    o  the relayed transport address or addresses;
> > > >    [...]
> > > >
> > > >    [...]
> > > >    address.  The relayed transport address MUST be unique across all
> > > >    allocations, so it can be used to uniquely identify the allocation.
> > > >
> > > > nit: there's maybe a singular/plural mismatch going on here, but I
> > > > don't have any good ideas.
> > > >
> > > > Section 7.1
> > > >
> > > >    If the client wishes to obtain one IPv6 and one IPv4 relayed
> > > >    transport address then it includes an ADDITIONAL-ADDRESS-FAMILY
> > > >    attribute in the request.  This attribute specifies that the server
> > > >    must allocate both address types.  The attribute value in the
> > > >    ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address
> > family).
> > > >    Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and
> > ADDITIONAL-
> > > >    ADDRESS-FAMILY attributes in the same request.  [...]
> > > >
> > > > This reads like setting REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
> > > > ADDRESS-FAMILY are mutually exclusive.  Is that the correct reading?
> > >
> > > Yes.
> > >
> > > > (Naively, one might expect that the thing named "additional"
> > > > is applied on top of the base-level request, so I have to ask.)
> > > >
> > > > Section 7.2
> > > >
> > > > Why do we only have a SHOULD-level requirement for authentication
> > > > of Allocate requests where 5766 had MUST?  Could we say "may allow
> > > > unauthenticated requests in order to support [use case] but
> > > > otherwise MUST require authentication" (with better wording)?  I
> > > > suppose this has probably been discussed ad nauseum already, so
> > > > feel free to point me at the archives before getting into an actual
> discussion.
> > >
> > > You missed the next line, it says the authentication of the request
> > > is optional to allow TURN servers provided by the local or access
> > > network to accept Allocation requests from new and/or guest users in
> > > the network who do not necessarily possess long term credentials for
> > > STUN authentication and its security implications are discussed in
> > > [RFC8155].
> >
> > I saw the next line; the current formulation also allows non-use of
> > authentication in other  situations, which is why I suggested an
> > alternate wording.
> >
> > > The WG spent several cycles discussing the downgrade of a MUST level
> > requirement (please see https://tools.ietf.org/html/rfc8155#section-9).
> >
> > To be clear, I do not object to removing the MUST for the local-use
> > case; I'm concerned with the wording of the text that, as written,
> > also weakens the requirement for all other cases.
> 
> Got it, updated step as follows:
> 
>    1.   The TURN server provided by the local or access network MAY
>         allow unauthenticated request in order to accept Allocation
>         requests from new and/or guest users in the network who do not
>         necessarily possess long term credentials for STUN
>         authentication and its security implications are discussed in
>         [RFC8155].  Otherwise, the server MUST require that the request
>         be authenticated.  If the request is authenticated, the
>         authentication MUST be done either using the long-term credential
>         mechanism of [I-D.ietf-tram-stunbis] or the STUN Extension for
>         Third-Party Authorization [RFC7635] unless the client and server
>         agree to use another mechanism through some procedure outside
>         the scope of this document.
> 
> >
> > > >
> > > >    7.   If the server does not support the address family requested by
> > > >         the client in REQUESTED-ADDRESS-FAMILY or is disabled by local
> > > >         policy, it MUST generate an Allocate error response, and it MUST
> > > >         include an ERROR-CODE attribute with the 440 (Address Family not
> > > >         Supported) response code.  [...]
> > > >
> > > > nit: "or is disabled" needs a subject.
> > >
> > > Fixed, updated text as follows:
> > > If the server does not support the address family requested by the
> > > client in
> > REQUESTED-ADDRESS-FAMILY or if the allocation of the requested address
> > family is disabled by local policy, it MUST generate an Allocate error
> > response, and it MUST include an ERROR-CODE attribute with the 440
> > (Address Family not Supported) response code.
> >
> > Thanks
> >
> > > >    9.   The server checks if the request contains an ADDITIONAL-
> ADDRESS-
> > > >         FAMILY attribute.  If yes, and the attribute value is 0x01 (IPv4
> > > >         address family), then the server rejects the request with a 400
> > > >         (Bad Request) error.  Otherwise, the server checks if it can
> > > >         allocate relayed transport addresses of both address types.  If
> > > >         the server cannot satisfy the request, then the server
> > > > rejects
> > > >
> > > > What are "both" address types?
> > >
> > > Both IPv4 and IPv6 address families.
> >
> > I guess once I realize that "ADDITIONAL-ADDRESS-FAMILY" is just code
> > for
> > "IPv4 and IPv6" with no other options, this doesn't look as unclear.
> >
> > > > We only have the ADDITIONAL-ADDRESS- FAMILY (which contains one
> > > > type) and no REQUESTED-ADDRESS-FAMILY.
> > >
> > > If ADDITIONAL-ADDRESS-FAMILY is used, the server will allocate both
> > > IPv4
> > and IPv6 relayed transport addresses.
> > >
> > > >
> > > > Section 8.1
> > > >
> > > >    When refreshing a dual allocation, the client includes REQUESTED-
> > > >    ADDRESS-FAMILY attribute indicating the address family type that
> > > >    should be refreshed.  If no REQUESTED-ADDRESS-FAMILY is
> > > > included
> > then
> > > >    the request should be treated as applying to all current allocations.
> > > >    The client MUST only include family types it previously allocated and
> > > >    has not yet deleted.  [...]
> > > >
> > > > I'm a bit confused about "only include family types" plural; I
> > > > thought there could only be at most one REQUESTED-ADDRESS-FAMILY
> > and
> > > > that it would only indicate one family type.  So how could  there
> > > > be multiple types getting included by the client?
> > >
> > > Good catch, replaced "types" with "type"
> >
> > (It needs a definite article, then for "only include the family type")
> 
> Done.
> 
> Cheers,
> -Tiru
> 
> >
> > > >
> > > > Section 11.5
> > > >
> > > > [check that "type and code" is valid in both ICMPv4 and v6]
> > >
> > > Yes, it is valid.
> >
> > Sorry; that was supposed to be a note to myself!
> > But yes, luckily for me this is not the point of difference between
> > ICMPv4 and ICMPv6 that I was vaguely remembering.
> >
> > > >
> > > > Section 12
> > > >
> > > >    Reserved values may be used in the future by other protocols.  When
> > > >    the client uses channel binding, it MUST comply with the
> > > >    demultiplexing scheme discussed above.
> > > >
> > > > "channel binding" is a term of art in the security world; is this
> > > > usage intended to roughly mean "channel multiplexing"?
> > > > (I do see that the subsections are talking about the specific
> > > > ChannelBind request, so I assume so; I just want to double check.)
> > >
> > > Yes,  a channel binding is created or refreshed using a ChannelBind
> > transaction (Please see Section 12.1).
> >
> > Great.  Well, not great that there's a collision of jargon, but it's
> > way too late to do anything about, now.
> >
> > > >
> > > >
> > > > Section 13
> > > >
> > > >    The descriptions below have two parts: a preferred behavior and an
> > > >    alternate behavior.  The server SHOULD implement the preferred
> > > >    behavior.  Otherwise, the server MUST implement the alternate
> > > >    behavior and MUST NOT do anything else for the reasons detailed in
> > > >    [RFC7915].  [...]
> > > >
> > > > RFC 5766 had this split on a per-field basis, but this text
> > > > suggests that if the preferred behavior is not possible for a
> > > > given field, then the alternate behavior is used for the entire packet.
> > > > I note that section 14 does retain the "for a particular field"
> > > > language for UDP-to-UDP relaying, as do section 15 for TCP-to-UDP
> > > > relaying and section 16 for UDP-to-TCP relaying.
> > >
> > > Good point, fixed text as follows:
> > > Otherwise, if that is not possible for a particular field, the
> > > server MUST
> > implement the alternate behavior and MUST NOT do anything else for the
> > reasons detailed in [RFC7915].
> > >
> > > >
> > > > Section 13.2
> > > >
> > > > Is this flow label text consistent with both the inbound and
> > > > outbound translation directions (specifically, using relayed/peer
> > > > addresses in the 5- tuple to identify the flow)?
> > > >
> > > >       If the incoming packet did not include a Fragment header and the
> > > >       outgoing packet size exceeds the outgoing link's MTU, the TURN
> > > >       server drops the outgoing packet and send an ICMP message of type
> > > >       2 code 0 ("Packet too big") to the sender of the incoming packet.
> > > >        If the packet is being sent to the peer, the TURN server reduces
> > > >       the MTU reported in the ICMP message by 48 bytes to allow room
> for
> > > >       the overhead of a Data indication.
> > > >
> > > > (nit?) "If the packet is being send to the peer" seems to
> > > > grammatically refer to the outgoing packet that would exceed link
> > > > MTU, as opposed to the ICMP message being generated.  But I think
> > > > it's supposed to refer to the ICMP message being generated, which
> > > > has
> > not yet been referred to as a "packet"
> > > > in this text.
> > >
> > > Suresh raised the same comment, fixed text as follows:
> > > If the ICMPv6 packet ("Packet too big") is being sent to the peer,
> > > the TURN
> > server reduces the MTU reported in the ICMP message by 48 bytes to
> > allow room for the overhead of a Data indication.
> >
> > Great; t hanks
> >
> > > >
> > > > Section 13.3
> > > >
> > > > [Same comment about ICMP packet generation/grammar]
> > >
> > > Fixed text as follows:
> > > If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4)
> > > is
> > being sent to the peer, the TURN server SHOULD reduce the MTU reported
> > in the ICMP message by 48 bytes to allow room for the overhead of a
> > Data indication.
> > >
> > > >
> > > > Section 15
> > > >
> > > > Maybe note that SIP and WebRTC are the primary consumers of TURN?
> > >
> > > Yes, it is mentioned in several places in the document that WebRTC
> > > and SIP
> > use TURN.
> >
> > Okay; my fault for only looking at the diff, probably.
> >
> > > >
> > > >                                                         Even if both
> > > >    TCP-AO and UDP authentication would be used between TURN client
> > and
> > > >    server, it would not change the end-to-end security properties of the
> > > >    UDP payload being relayed.  [...]
> > > >
> > > > I wonder if we even need to say "UDP" in "payload being relayed".
> > >
> > > Replaced "UDP" with "application"
> > >
> > > >
> > > > Section 16
> > > >
> > > >    Fragmentation
> > > >
> > > >       Preferred Behavior: Any fragmented packets are reassembled in the
> > > >       server and then forwarded to the client over the TCP connection.
> > > >       ICMP messages resulting from the UDP datagrams sent to the peer
> > > >       MUST be forwarded to the client using TURN's mechanism for
> > > >       relevant ICMP types and codes.
> > > >
> > > > As in section 12.7, I wonder if this MUST could be seen as
> > > > overriding other logic for ICMP handling.
> > >
> > > Modified text for clarity as follows:
> > >
> > > ICMP messages resulting from the UDP datagrams sent to the peer are
> > > processed by the server as described in Section 11.5 and forwarded
> > > to the client using TURN's mechanism for relevant ICMP types and codes.
> >
> > Thanks
> >
> > > >
> > > > Section 21.16
> > > >
> > > > I agree with the secdir reviewer that there is at least potential
> > > > for username and realm to be sensitive.
> > >
> > > I proposed to add the following text:
> > >
> > >    If the TURN client and server use the STUN Extension for Third-Party
> > >    Authorization [RFC7635] (for example it is used in WebRTC), the
> > >    username does not reveal the real user's identity, the USERNAME
> > >    attribute carries an ephemeral and unique key identifier.  If the
> > >    TURN client and server use the STUN long-term credential mechanism
> > >    and the username reveals the real user's identity, the client needs
> > >    to use (D)TLS transport between the client and the server or use the
> > >    USERHASH attribute instead of the USERNAME attribute to anonynmize
> > >    the username.
> > >
> > >    If the TURN client and server use the STUN long-term credential
> > >    mechanism and realm information is privacy sensitive, TURN can be run
> > >    over (D)TLS.  As a reminder, STUN Extension for Third-Party
> > >    Authorization does not use realm.
> >
> > Excellent; thank you!
> >
> > > >
> > > > Section 21.4
> > > >
> > > > Do we need references for Teredo and/or 6to4?
> > >
> > > https://tools.ietf.org/html/rfc6156 did not add references to Teredo
> > > and
> > 6to4.
> >
> > Okay; just wanted to check.
> >
> > > >
> > > > Section 22
> > > >
> > > >    The codepoints for the STUN error codes defined in this specification
> > > >    are listed in Section 19.  [IANA is requested to update the reference
> > > >    from [RFC5766] to RFC-to-be for the STUN error codes listed in
> > > >    Section 19.]
> > > >
> > > > (I think some of them are from RFC 6156 as well as from 5766.)
> > >
> > > Yes, added RFC6156.
> > >
> > > >
> > > > Section 23
> > > >
> > > > It seems prudent to revisit these listed IAB Considerations for
> > > > whether the situation has changed in the past ten years (though I
> > > > don't have any specific points that I would change).
> > > >
> > > > Section 25
> > > >
> > > > (nit) are these really "updates" to RFC 6156 so much as
> > > > incorporating its content wholesale into the core TURN specification?
> > >
> > > Yes, several sections in RFC6156 are updated.
> >
> > Okay, thanks.
> >
> > -Ben