Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Fri, 19 July 2019 05:30 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 D12321200FB for <tram@ietfa.amsl.com>; Thu, 18 Jul 2019 22:30:15 -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=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 SNfn0UrNe1KK for <tram@ietfa.amsl.com>; Thu, 18 Jul 2019 22:30:11 -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 047801200D7 for <tram@ietf.org>; Thu, 18 Jul 2019 22:30:10 -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=1563513539; 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=1748xzme8SSWJxnrOYOn6ECb/9v+cQzNi3SEpO JEDVE=; b=lPQfOElkAs7m9Dn7V7jivM1SGjG0/t8qGa3Donbg sWWJ8NLSDqlJEUCeFs9qoUbYh3DaKZXHb2wcV9+HCis8Me+frQ 8WfN4hAbywdJJTjNP6zek8KGq3PiaWWjbjKs5DEgo6JOov0m9r 9MJoWNomdEU+GgzJTPpxNwCWvGL+kWE=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-228-BzK8DFVxPXScSRpIuC5uRQ-1; Fri, 19 Jul 2019 01:30:00 -0400
Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6f0d_083f_215f385b_2258_4474_a1c8_150a5e68324f; Thu, 18 Jul 2019 23:18:57 -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; Thu, 18 Jul 2019 23:29:48 -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; Thu, 18 Jul 2019 23:29:49 -0600
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Jul 2019 23:29:48 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R/n3CyS5BRykXky+HHx9asXSLk2lRZ6g6+aBLf02Tr+si+Q1J2h8MhIzxFbwtj08Qnrf7/gQtpKlc01fxUAFAsCALmMEVoj38m+vuX65v/N8nHTtrlWP8dGdB3bd5F9tgr/nnWrILXaJ+QdwHSFuV0xrwpRUU7vb9BmG0/rCjQtatRum+9j59vQSr9bEaOfzchgKSoPgQ0fBOi4lmkjHShCzGnAmHyIs1U3vknUfyTvXnyQxPJKDjQBLCt7qvM1GIY3Sdn+nLUmMT9NwohFRUIkNoTdH966XYGOYKu97XBEZ+KBGBiEcbFlFymt2ANk3dLAMx84+u/6+oKpsmlcLpw==
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=1748xzme8SSWJxnrOYOn6ECb/9v+cQzNi3SEpOJEDVE=; b=WpzqIagUC0US/xvlQUb4SpqSTRRDqn6qx5f1Bc6PSG5l6krvX1+OSTHlidvk5la073ttS7v+soJj4B//NDQ2PfomwXcMXrh4P9vOeYpUmAviQrBKwQ66Rn9BgU6il21Sjp25mK7ndm6ZW20ntLWEpp9vZhdjYFXGF4nK7L2vzSHEXhJKIXNXBTcX85U/SF440Pslf0JtXGvWAMtQwFal7Y4ClKRhPKu/3c1HuiOUUb6AZAFfRUOWiSLgzmDrJksfu0Cxc0OIUDzJxjRyET81Hqzhx/UGCcw9RqKWSCo3PwafuLEnLWzoMaNzSXJe74XlP1KPgh9rJ+oea6dVTkI2/A==
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 DM5PR16MB2262.namprd16.prod.outlook.com (52.132.142.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Fri, 19 Jul 2019 05:29:45 +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; Fri, 19 Jul 2019 05:29:45 +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/G2g6Mwv66bFIQEggAKxEACAAC4dEIAI2iEAgACJI0A=
Date: Fri, 19 Jul 2019 05:29:44 +0000
Message-ID: <DM5PR16MB1705EB7A9FC06A1455EE69C6EACB0@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> <20190718201019.GI83144@kduck.mit.edu>
In-Reply-To: <20190718201019.GI83144@kduck.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: [185.221.69.46]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c6d0b7ed-6a0f-4f06-ff2f-08d70c0a1bc9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2262;
x-ms-traffictypediagnostic: DM5PR16MB2262:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <DM5PR16MB22626E8D294D7086EF135664EACB0@DM5PR16MB2262.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01039C93E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(39860400002)(366004)(346002)(396003)(32952001)(51914003)(199004)(54094003)(13464003)(189003)(9686003)(25786009)(53946003)(3846002)(14454004)(2171002)(6306002)(30864003)(76176011)(55016002)(305945005)(6116002)(54906003)(14444005)(5024004)(229853002)(256004)(53546011)(81156014)(71190400001)(71200400001)(7696005)(26005)(102836004)(6506007)(186003)(2906002)(53936002)(86362001)(966005)(6246003)(476003)(6436002)(478600001)(7736002)(74316002)(11346002)(6916009)(446003)(4326008)(66946007)(5660300002)(99286004)(66066001)(76116006)(8676002)(316002)(8936002)(64756008)(66556008)(66476007)(80792005)(52536014)(33656002)(81166006)(66446008)(68736007)(486006)(85282002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2262; 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: OcqN+FDxp3IktPCHjU9G4X3q35J1q0a5wKIsFsBohrEw9yDO8AWZ4O7fViPCm1qnsvcJ/Nn1iGjSwpzVgZ25JyO0Keo5FTf7byNwgDfWmzbIZXWfWHG+GRtfaCSF0FNagZOg0iFNx468KckK97uLGfTtkFhbmbtjiB/nWy8Xo7ywSS48HpatjS0EkaIlKW/8U0qmkoD2kdC/yZy65vOIOLFYVBK8gy8zeJM8Uui+YPLpRCuPGk9dP6jFNceKGU0Ry/fIuUXYs+7hHh0vIueIIwN0QpuPcgR5G68fvonQwdCB2qnXQkPKzGnLDZdXH7TZDKvyto8ee1Gf6kdEfOv1ic2vBFObbq/SLhw5j3Re1kr8hC9hLt9c8pSYERM+oktYPIg3OjslL7NbPYAt7PcM8/9PFqgNuxdubuKXEgkMXco=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c6d0b7ed-6a0f-4f06-ff2f-08d70c0a1bc9
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 05:29:44.9301 (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: DM5PR16MB2262
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 <6593> : inlines <7120> : streams <1827777> : uri <2869217>
X-MC-Unique: BzK8DFVxPXScSRpIuC5uRQ-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/ZT9nf6-Fvds8qWt95gTVZwFTxXk>
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: Fri, 19 Jul 2019 05:30:16 -0000
Hi Ben, Please see inline > -----Original Message----- > From: Benjamin Kaduk <kaduk@mit.edu> > Sent: Friday, July 19, 2019 1:40 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. > > On Sat, Jul 13, 2019 at 06:10:55AM +0000, Konda, Tirumaleswar Reddy wrote: > > 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. > > I was thinking more like "When only a single address type is desired, the > REQUESTED-ADDRESS-FAMILY attribute is used to explicitly request [...]. > If both IPv4 and IPv6 are desired, the single ADDITIONAL-ADDRESS-FAMILY > attribute indicates a request to the server to allocate [...]". Works for me, updated draft. > > > > > > > > > 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. > > That should work (though I wonder if the RFC Editor will tweak things, since > the "otherwise" is separated by another sentence from the initial case it's > contrasting with). > > I do note that the diff link you sent out also removes some text (in a 4.x or > 5.x section?) about "the server MUST demand that all requests from the > client be authenticated" after the "MUST implement [long-term credentials]" > requirement. Yes, removed above text from Section 5 to avoid discussing the requirement normatively twice (Thanks to the suggestion from Mirja). > It might be worth making a forward reference from that > location to this text, if possible. Done, update text as follows: TURN servers and clients MUST implement this mechanism, and the authentication options are discussed in Section 7.2. Cheers, -Tiru > > Thanks, > > Ben > > > > > > > > > > > > > > 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 > >
- [tram] Benjamin Kaduk's Discuss on draft-ietf-tra… Benjamin Kaduk via Datatracker
- Re: [tram] Benjamin Kaduk's Discuss on draft-ietf… Konda, Tirumaleswar Reddy
- Re: [tram] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [tram] Benjamin Kaduk's Discuss on draft-ietf… Konda, Tirumaleswar Reddy
- Re: [tram] Benjamin Kaduk's Discuss on draft-ietf… Konda, Tirumaleswar Reddy
- Re: [tram] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [tram] Benjamin Kaduk's Discuss on draft-ietf… Konda, Tirumaleswar Reddy