From nobody Fri Feb 2 05:23:05 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FF212422F; Fri, 2 Feb 2018 05:23:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Gonzalo Camarillo To: X-Test-IDTracker: no X-IETF-IDTracker: 6.71.0 Auto-Submitted: auto-generated Precedence: bulk Cc: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren , Gonzalo.Camarillo@ericsson.com, tasveren@rbbn.com, iesg-secretary@ietf.org Message-ID: <151757778363.25590.13140092755733279917.idtracker@ietfa.amsl.com> Date: Fri, 02 Feb 2018 05:23:03 -0800 Archived-At: Subject: [tram] Publication has been requested for draft-ietf-tram-stunbis-15 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 13:23:04 -0000 Gonzalo Camarillo has requested publication of draft-ietf-tram-stunbis-15 as Proposed Standard on behalf of the TRAM working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ From nobody Mon Feb 5 05:54:21 2018 Return-Path: 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 8BAF612D7EF for ; Mon, 5 Feb 2018 05:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive.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 6ydl6ytp0H-H for ; Mon, 5 Feb 2018 05:54:18 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3AD1252BA for ; Mon, 5 Feb 2018 05:54:18 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id a7so24045608otk.9 for ; Mon, 05 Feb 2018 05:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=V2MYkiby9ss8GEw2YmvKW1oLYGX2P9wom9LcPzn78os=; b=kJvo1AzkUobWWl89VY2x0lekJ7TBaqgpzpA8JFr1xTgjjszzAVpLWJvfYTgvES5pVb tqEuRqw8YWwuqICPcX1VVOg778YtYM6AzV+nyH+bNkUXz1cO1bNnS3a+h2TFg85yc/Le n6nor1NQJX6ElAgbKdQkXopms5iymeFb0QgJSxpsCteFrHDQPhglPH/gO/Iah/DdBl4W u5RFgI0NJABtcCJ2374CHMH/C75VU8mo7J+7KwSISObGgRAP9zZYZiztbDr+KmmZKX7K 2nbk5tfgb86UhSmVOYuM5UMo7AbVYVMrWuZfDVEl5oVQhXgkOfOn/KPbM8wiz/fWmOot qgtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=V2MYkiby9ss8GEw2YmvKW1oLYGX2P9wom9LcPzn78os=; b=e32p3uHQBEHaE6y/pGcCV9KX8qaNokG5VJ6qyWPUjT6rfIUS6h62eO1smRK30qnM1/ otldrZVYg8q4jUC1cyivPCeaTSupAgF+iZuwOp/SmBNo05oO9SZlOcIg99JmaAgrTkvR wZKH2RBSFsznkBcpbJuS5d69jsHCyTZVqlFEd6Nqv7mAQn8JVLQzhX+oOMXMkVfVQ8K7 2ByDoEqK5xXBpA8pOqEe2ebwT7q+Cdli6UGG/2LZzmPymrr7QJcgNX9TezR3j+QNOxII ryo8lYFi+G8ik9bSPEuF8DQDy/5ylGmTkQx/m9Wn0lCJNESDgw88+me2cZhAvnXx0A1p /RWA== X-Gm-Message-State: AKwxytchY3WjZ8vN+Htq+e0M7ZWj6slja4QI7LLPnU9D4QxJtQ48tF1j xfvPXGDqpOIOuBn1aGT73mxDS1RDjYtkCWmO/V+/AO3D X-Google-Smtp-Source: AH8x225aNtxFo8GatnwVf2H2ZkbSGlhkbISgR/wHOnr2Iu2UElkMvLd8srZppK7UW9s+OSjFWrscLyhOL5yw6w95ONc= X-Received: by 10.157.45.170 with SMTP id g39mr25402840otb.80.1517838857710; Mon, 05 Feb 2018 05:54:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.139.121 with HTTP; Mon, 5 Feb 2018 05:53:57 -0800 (PST) From: Simon Perreault Date: Mon, 5 Feb 2018 08:53:57 -0500 Message-ID: To: tram@ietf.org Content-Type: multipart/alternative; boundary="94eb2c038fa0f12819056477656d" Archived-At: Subject: [tram] Shepherd needed X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 13:54:20 -0000 --94eb2c038fa0f12819056477656d Content-Type: text/plain; charset="UTF-8" All, We're looking for someone to help take draft-etf-tram-stun-pmtud across the finish line. Someone with free cycles to help write a proto writeup and act as shepherd throughout the IESG process. This is a relatively low amount of work: maybe 1-2 hours for kickoff and then a few minutes per week until the draft is published. This is a good opportunity to get to know the IETF processes more intimately. Any volunteer? Thanks, Simon & Gonzalo --94eb2c038fa0f12819056477656d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We're looking for someone to h= elp take draft-etf-tram-stun-pmtud across the finish line. Someone with fre= e cycles to help write a proto writeup and act as shepherd throughout the I= ESG process. This is a relatively low amount of work: maybe 1-2 hours for k= ickoff and then a few minutes per week until the draft is published. This i= s a good opportunity to get to know the IETF processes more intimately.

Any volunteer?

Thanks,
=
Simon & Gonzalo
--94eb2c038fa0f12819056477656d-- From nobody Mon Feb 5 16:07:08 2018 Return-Path: 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 95DB7129C53 for ; Mon, 5 Feb 2018 16:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 S_Pcw7nD4V8r for ; Mon, 5 Feb 2018 16:07:03 -0800 (PST) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98691127869 for ; Mon, 5 Feb 2018 16:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u3//5KfY0DVtAO+OPXwp2Pf1A8ARq7u0HTXIoQ+Zzh0=; b=JGOkoloZycfwVcCJWLecwDOcmg0XsPaq+XpDubmWkGEKpDilPnCWO7Zl2LnCZgFEGr2jkaLC/7D+q5mvdGV3t7dJReWC9z0bKZe7UZbUZqIHGi1uj5o1hcOz537KC+MNxaxopHxg6I3/2IEZP+MzkY6ETz5JwPapbpn3Cz/imaU= Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0184.outbound.protection.outlook.com [216.32.181.184]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-23-UfG6bWV5Mf6mHzPj38tdLw-1; Mon, 05 Feb 2018 19:07:01 -0500 Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB3062.namprd03.prod.outlook.com (10.171.245.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Tue, 6 Feb 2018 00:06:59 +0000 Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([10.171.245.165]) by CY4PR03MB3160.namprd03.prod.outlook.com ([10.171.245.165]) with mapi id 15.20.0464.015; Tue, 6 Feb 2018 00:06:59 +0000 From: "Asveren, Tolga" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] Shepherd needed Thread-Index: AQHTnojYAfSb/n0HD0SV8YC+yh6UCqOWf2qA Date: Tue, 6 Feb 2018 00:06:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.251.142] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR03MB3062; 20:zrzzOTnIU+AtsODYPzJgAA3NCJPSU78gcjTxzSJ8/b8QoTuqqDIUGYE+f+AYRUbWlVUkHONOyfJdwBT2pqBp/XVIXjfG6bWM8R1u/Ree6KeJy+616BwuyBdbOoy0Gkzj8gmAzj/b4xiv0iHq2bpEZIwaqgUbSQf938eXFPwA4I4= x-ms-office365-filtering-correlation-id: b8ae2785-c9b8-4c6a-d36a-08d56cf58ae6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR03MB3062; x-ms-traffictypediagnostic: CY4PR03MB3062: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR03MB3062; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB3062; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(396003)(39850400004)(366004)(376002)(189003)(199004)(77096007)(6116002)(68736007)(33656002)(99286004)(74316002)(186003)(105586002)(66066001)(5660300001)(106356001)(2950100002)(6246003)(97736004)(53936002)(2501003)(790700001)(102836004)(6506007)(59450400001)(53546011)(3660700001)(2906002)(3280700002)(229853002)(316002)(25786009)(7696005)(55016002)(54896002)(110136005)(6306002)(76176011)(6436002)(9686003)(8936002)(86362001)(478600001)(81156014)(26005)(81166006)(14454004)(2900100001)(8676002)(7736002)(3846002)(443494004); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB3062; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-microsoft-antispam-message-info: VUfb//M7rlZylvzxfGA2mWv7mED99oZpsAwEQmGFwglh5SorXo7VVncRWUJXXw3zgPGTqCWDInK8Gae407jIPA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8ae2785-c9b8-4c6a-d36a-08d56cf58ae6 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 00:06:59.5338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB3062 X-MC-Unique: UfG6bWV5Mf6mHzPj38tdLw-1 Content-Type: multipart/alternative; boundary="_000_CY4PR03MB3160D2BBB2DC7D357968DF40A5FD0CY4PR03MB3160namp_" Archived-At: Subject: Re: [tram] Shepherd needed X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 00:07:07 -0000 --_000_CY4PR03MB3160D2BBB2DC7D357968DF40A5FD0CY4PR03MB3160namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 U2ltb24sIEdvbnphbG8sDQoNCkkgY2FuIHNwZW5kIHNvbWUgY3ljbGVzIG9uIHRoaXMuIFBsZWFz ZSBsZXQgbWUga25vdyBpZiB5b3Ugd2FudCBtZSB0byB0YWtlIG9uIGl0Lg0KDQpUaGFua3MsDQpU b2xnYQ0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU2ltb24gUGVycmVhdWx0DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDUsIDIwMTggODo1 NCBBTQ0KVG86IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFt0cmFtXSBTaGVwaGVyZCBuZWVkZWQN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5PVElDRTogVGhpcyBlbWFpbCB3 YXMgcmVjZWl2ZWQgZnJvbSBhbiBFWFRFUk5BTCBzZW5kZXINCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCkFsbCwNCg0KV2UncmUgbG9va2luZyBmb3Igc29tZW9uZSB0byBoZWxw IHRha2UgZHJhZnQtZXRmLXRyYW0tc3R1bi1wbXR1ZCBhY3Jvc3MgdGhlIGZpbmlzaCBsaW5lLiBT b21lb25lIHdpdGggZnJlZSBjeWNsZXMgdG8gaGVscCB3cml0ZSBhIHByb3RvIHdyaXRldXAgYW5k IGFjdCBhcyBzaGVwaGVyZCB0aHJvdWdob3V0IHRoZSBJRVNHIHByb2Nlc3MuIFRoaXMgaXMgYSBy ZWxhdGl2ZWx5IGxvdyBhbW91bnQgb2Ygd29yazogbWF5YmUgMS0yIGhvdXJzIGZvciBraWNrb2Zm IGFuZCB0aGVuIGEgZmV3IG1pbnV0ZXMgcGVyIHdlZWsgdW50aWwgdGhlIGRyYWZ0IGlzIHB1Ymxp c2hlZC4gVGhpcyBpcyBhIGdvb2Qgb3Bwb3J0dW5pdHkgdG8gZ2V0IHRvIGtub3cgdGhlIElFVEYg cHJvY2Vzc2VzIG1vcmUgaW50aW1hdGVseS4NCg0KQW55IHZvbHVudGVlcj8NCg0KVGhhbmtzLA0K U2ltb24gJiBHb256YWxvDQo= --_000_CY4PR03MB3160D2BBB2DC7D357968DF40A5FD0CY4PR03MB3160namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNpbW9uLCBHb256YWxvLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNhbiBzcGVu ZCBzb21lIGN5Y2xlcyBvbiB0aGlzLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IHdhbnQgbWUg dG8gdGFrZSBvbiBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9sZ2E8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiB0cmFtIFttYWls dG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5TaW1vbiBQZXJy ZWF1bHQ8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IDg6NTQgQU08 YnI+DQo8Yj5Ubzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3RyYW1d IFNoZXBoZXJkIG5lZWRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIi IHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Tk9USUNFOiBUaGlzIGVtYWlsIHdhcyByZWNlaXZlZCBmcm9tIGFuIEVYVEVSTkFMIHNlbmRl cjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGln bj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsLDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UncmUgbG9va2luZyBmb3Igc29tZW9uZSB0 byBoZWxwIHRha2UgZHJhZnQtZXRmLXRyYW0tc3R1bi1wbXR1ZCBhY3Jvc3MgdGhlIGZpbmlzaCBs aW5lLiBTb21lb25lIHdpdGggZnJlZSBjeWNsZXMgdG8gaGVscCB3cml0ZSBhIHByb3RvIHdyaXRl dXAgYW5kIGFjdCBhcyBzaGVwaGVyZCB0aHJvdWdob3V0IHRoZSBJRVNHIHByb2Nlc3MuIFRoaXMg aXMgYSByZWxhdGl2ZWx5IGxvdyBhbW91bnQgb2Ygd29yazogbWF5YmUNCiAxLTIgaG91cnMgZm9y IGtpY2tvZmYgYW5kIHRoZW4gYSBmZXcgbWludXRlcyBwZXIgd2VlayB1bnRpbCB0aGUgZHJhZnQg aXMgcHVibGlzaGVkLiBUaGlzIGlzIGEgZ29vZCBvcHBvcnR1bml0eSB0byBnZXQgdG8ga25vdyB0 aGUgSUVURiBwcm9jZXNzZXMgbW9yZSBpbnRpbWF0ZWx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbnkgdm9sdW50ZWVyPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW1vbiAmYW1w OyBHb256YWxvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_CY4PR03MB3160D2BBB2DC7D357968DF40A5FD0CY4PR03MB3160namp_-- From nobody Tue Feb 6 11:42:57 2018 Return-Path: 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 7B0E9124B17; Tue, 6 Feb 2018 11:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pytZ_aNdS0ew; Tue, 6 Feb 2018 11:42:49 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D353F12773A; Tue, 6 Feb 2018 11:42:48 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id v139so2194652ywg.4; Tue, 06 Feb 2018 11:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=nwxlE1++5FiOBogcEA9cAydssF4a4lGB0CKaRrGR6IE=; b=WVXAtojQrRmGpYTpogZHm5YY9HRA4faRkA49UqcFxnauqmGZAbD1ynmEEIPon3HkDd QoGYuKCfxX+6+v9TtA0THLMaAUod5ziVN7spcTF2dGrNa7mD3r8Ls9iYHovzqxPgHmW3 5YqumHQbrbNBkeoqbM/8G6jTY5xgl8X8XfN7yPnOF9bkNywKOl1k7o5azNKngARgFuVR AZqfhXX00aWuJBqFQyaux4CqlItM7qWZavzijVIGVWLyDdijL53YJ8sQKp/pkWPl7Cz8 xhAhbUt9shMjJwKruMdsEIISNyJDVDvSHr3/Wwz9te6l/UsiWgp+tyyTunTQym2IgS/8 vI2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=nwxlE1++5FiOBogcEA9cAydssF4a4lGB0CKaRrGR6IE=; b=M3SUGXcWzeMs9s1qtSe8oJnrwLEb8D17jK/OCT7w6z05Dp/WSj15a4E/rEmRwCej40 aoT0J0Lg2jBC6iX3pGqbTcscbr/oQuP2N6Fj8LYld4gTN2hw7miGip81tbCZCTjb37IJ FMwwTKi3cyL3eEoQdltm8isRPyNxWHJFCtCtXg7EyO5cShumto0+Pg4b2uctVj8ecqsQ dnnvP+vS05bmTVmGVxwgtvuwTbIfjsnkAdCCZDzGfo3yisj6OA3S8YZ45xV4M8hYbkCR tsHp8sOZfs6zeR7i+e/jNCHgRZP0JXOy+xQHEKRtvMUl21bOSJJU9j4cFOx1Z1JIv144 4GHw== X-Gm-Message-State: APf1xPCW6AbuQgc7lYXSmnSbPX4HO66mrfixdD5f4XpMV4EftmDlGDce yNR1GV1sdQSAmB7CH1dbiVtuX+kxXhnKSCVaRSY= X-Google-Smtp-Source: AH8x227awybiKjJ7yLGmV5KnD7RKgs/pFBIskTrrV7ZCg1DOHlfmuH1f8WXJHEbqsP/se02yL2vBQGMX/qEcuwfjsOQ= X-Received: by 10.37.133.69 with SMTP id f5mr2419309ybn.54.1517946167970; Tue, 06 Feb 2018 11:42:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.21.201 with HTTP; Tue, 6 Feb 2018 11:42:47 -0800 (PST) From: Spencer Dawkins at IETF Date: Tue, 6 Feb 2018 13:42:47 -0600 Message-ID: To: Gonzalo Camarillo Cc: tram-chairs@ietf.org, tram@ietf.org, tasveren@rbbn.com Content-Type: multipart/alternative; boundary="089e08250e8821517705649062ef" Archived-At: Subject: [tram] AD Evaluation of draft-ietf-tram-stunbis-15 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 19:42:55 -0000 --089e08250e8821517705649062ef Content-Type: text/plain; charset="UTF-8" Dear All, On Fri, Feb 2, 2018 at 7:23 AM, Gonzalo Camarillo < gonzalo.camarillo@ericsson.com> wrote: > Gonzalo Camarillo has requested publication of draft-ietf-tram-stunbis-15 > as Proposed Standard on behalf of the TRAM working group. This looks good. I have a couple of nits, but I'll request Last Call now, and you can consider them at an appropriate time. Thanks! Spencer -- Is there a reference for the SIP practice described here The structure of the key when used with long-term credentials facilitates deployment in systems that also utilize SIP. Typically, SIP systems utilizing SIP's digest authentication mechanism do not actually store the password in the database. Rather, they store a value called H(A1), which is equal to the key defined above. that you could point to? In this text, o Made clear that the RTO is considered stale if there is no transactions with the server. there's a numbering mismatch - I'm not sure if this should be o Made clear that the RTO is considered stale if there are no transactions with the server. or something else. Unless you're intentionally using lower-case requirement keywords, and it doesn't look like you are, you may want to update your reference to RFC 2119, to https://tools.ietf.org/html/rfc8174. ADs have been mentioning this on their ballots. --089e08250e8821517705649062ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

On Fri, Feb 2, 2018 at 7:23 AM, Gonzalo Camarillo <g= onzalo.camarillo@ericsson.com> wrote:
Gonzalo Camarillo has requested publicat= ion of draft-ietf-tram-stunbis-15 as Proposed Standard on behalf of the TRA= M working group.

This looks good. I have a = couple of nits, but I'll request Last Call now, and you can consider th= em at an appropriate time.

Thanks!

<= /div>
Spencer

--

Is t= here a reference for the SIP practice described here
=C2=A0 =C2=A0 =C2=A0The structure of the key when used with long-term c= redentials
=C2=A0 =C2=A0 =C2=A0facilitates deployment in syst= ems that also utilize SIP.=C2=A0 Typically,=
=C2=A0 =C2=A0 =C2= =A0SIP systems utilizing SIP's digest authentication mechanism do not
=C2=A0 =C2=A0 =C2=A0actually store the password in the databas= e.=C2=A0 Rather, they store a
=
=C2=A0 =C2=A0 =C2=A0value calle= d H(A1), which is equal to the key defined above.

= that you could point to?

In this text,
<= br>
=C2=A0 =C2=A0o=C2=A0 = Made clear that the RTO is considered stale if there is no
= =C2=A0 =C2=A0 =C2=A0 transactions with the server.

there's a numbering mismatch - I'm not sure if this should be=C2= =A0

=C2=A0= =C2=A0o=C2=A0 Made clear that the RTO is considered stale if there are no<= span style=3D"white-space:pre">
=C2=A0 =C2=A0 =C2=A0 transactions with the server.

or something else.

Unless you'= re intentionally using lower-case requirement keywords, and it doesn't = look like you are, you may want to update your reference to RFC 2119, to https://tools.ietf.org/html/r= fc8174. ADs have been mentioning this on their ballots.
--089e08250e8821517705649062ef-- From nobody Tue Feb 6 11:51:10 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA39124B17; Tue, 6 Feb 2018 11:51:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk CC: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren , Gonzalo.Camarillo@ericsson.com, tasveren@rbbn.com, spencerdawkins.ietf@gmail.com, draft-ietf-tram-stunbis@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151794666374.18859.14880571375882811495.idtracker@ietfa.amsl.com> Date: Tue, 06 Feb 2018 11:51:03 -0800 Archived-At: Subject: [tram] Last Call: (Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 19:51:04 -0000 The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'Session Traversal Utilities for NAT (STUN)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Feb 8 23:44:45 2018 Return-Path: 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 2A0331243F6; Thu, 8 Feb 2018 23:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 ZPA71Uw6lwaH; Thu, 8 Feb 2018 23:44:41 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B283F12420B; Thu, 8 Feb 2018 23:44:40 -0800 (PST) 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=1518162279; h=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-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-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=GozE4coXupUlhAV4YuQNAmgVyYJbacjaAZLqP7 ADGJE=; b=YbUkVUIiTHmIUPCYxC938XnhwjBeGnlI2thDqP5W UxKoHv32i/iFRxM1tjXlhopDg859Bo1XYP+WhdFQqSnhuY3kfk Qse9ZDISlF6qAWUF5mgjwdfEKw+liOQ5g2Ol/d6nYC9xkHquEC OvyDladQjC+JDxF9qpuWH7q5+PQGNIg= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2f9b_27b2_9c5b95a7_2d2b_4ff9_82f6_25630c671072; Fri, 09 Feb 2018 01:44:38 -0600 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 02:44:35 -0500 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 02:44:34 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 9 Feb 2018 02:44:34 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 02:44:32 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1692.namprd16.prod.outlook.com (10.172.44.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 9 Feb 2018 07:44:32 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0464.017; Fri, 9 Feb 2018 07:44:32 +0000 From: "Konda, Tirumaleswar Reddy" To: Brandon Williams , "tram@ietf.org" CC: "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt Thread-Index: AQHTS8p5n4macCipKkK5ItbjZD/9kqLw/jXwgCArYYCAizHhAA== Date: Fri, 9 Feb 2018 07:44:32 +0000 Message-ID: References: <150874106330.24567.10025213746592540332@ietfa.amsl.com> <61866009-27d0-bdce-815f-7905d69cd661@akamai.com> In-Reply-To: <61866009-27d0-bdce-815f-7905d69cd661@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1692; 7:drRDQn4fqIgEOZPd5hihuoaChJ6IYu9Y1PBDjVvmwkrfKZ3JMF7r6Jyc0NKEkhsM6y1H8MiUgZTNiIJugoy/HTDK+DbYBntySRNKCzkMcDHK/fM5PkjKX4UAma3aX3Zpnh8LA+tUJ6RzqEUNTX8ceXE5zdBveIVnf8WLqZDGz5g5YS79wMY6fmDo4NlEYZu1lzNlv8ZK+ezZQK0s/mDPziU3cbAJpKU0nofNcdGqRt5GeGtYnT1zRfUFbfSD0x+p x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ff8b4a66-3c41-422e-f426-08d56f90f55c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(49563074)(7193020); SRVR:DM5PR16MB1692; x-ms-traffictypediagnostic: DM5PR16MB1692: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1692; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1692; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39850400004)(39380400002)(396003)(346002)(376002)(199004)(189003)(32952001)(51914003)(377424004)(13464003)(74316002)(66066001)(6436002)(106356001)(3660700001)(186003)(7736002)(305945005)(3280700002)(3846002)(6116002)(4326008)(55016002)(99936001)(2906002)(6506007)(102836004)(105586002)(53546011)(229853002)(59450400001)(7696005)(97736004)(76176011)(8936002)(2900100001)(77096007)(26005)(33656002)(8676002)(81166006)(316002)(81156014)(110136005)(5890100001)(86362001)(2950100002)(72206003)(14454004)(99286004)(966005)(2501003)(478600001)(5660300001)(53936002)(6306002)(9686003)(25786009)(80792005)(4001150100001)(68736007)(6246003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1692; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: KBD5E2V4L+gKSUd3RYI7M668yEXr5t0Oh2c6m31B2nzcTh5KOq46CePiucuslTLTElSg09mXsqFqz3ToLWpWrQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_DM5PR16MB1788DADED96D6137E0F8B93DEAF20DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ff8b4a66-3c41-422e-f426-08d56f90f55c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 07:44:32.4026 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1692 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 <6218> : inlines <6384> : streams <1778458> : uri <2589597> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 07:44:44 -0000 --_002_DM5PR16MB1788DADED96D6137E0F8B93DEAF20DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brandon, Thanks for the detailed review. I have updated the draft to address most of= the comments, please see the attached doc for responses to some of comment= s and nits. Cheers, -Tiru > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Sunday, November 12, 2017 11:34 PM > To: Konda, Tirumaleswar Reddy > ; tram@ietf.org > Cc: draft-ietf-tram-turnbis@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt >=20 > Hi Tiru, >=20 > I just finished a comprehensive review of the cumulative diffs against > RFC5766. See attached (let me know if you prefer me to resend as e-mail > body for list purposes). >=20 > You indicate that you addressed Marc's dual allocation related comments, > but this draft doesn't address his comprehensive review comments, right? >=20 > Please let me know a target for addressing the rest of his comments and > mine so I can try to stay on top of the shepherding work for the draft. >=20 > Thanks, > --Brandon > ________________________________________ > From: Konda, Tirumaleswar Reddy > > Sent: Monday, October 23, 2017 2:48 AM > To: tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt >=20 > This revision addresses comments from Brandon and dual allocation related > comments from Mark. >=20 > -Tiru >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Monday, October 23, 2017 12:14 PM > > To: i-d-announce@ietf.org > > Cc: tram@ietf.org > > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the TURN Revised and Modernized WG of the > > IETF. > > > > Title : Traversal Using Relays around NAT (TURN): Rel= ay Extensions > > to Session Traversal Utilities for NAT (STUN) > > Authors : Tirumaleswar Reddy > > Alan Johnston > > Philip Matthews > > Jonathan Rosenberg > > Filename : draft-ietf-tram-turnbis-12.txt > > Pages : 83 > > Date : 2017-10-22 > > > > Abstract: > > If a host is located behind a NAT, then in certain situations it can > > be impossible for that host to communicate directly with other hosts > > (peers). In these situations, it is necessary for the host to use > > the services of an intermediate node that acts as a communication > > relay. This specification defines a protocol, called TURN (Traversa= l > > Using Relays around NAT), that allows the host to control the > > operation of the relay and to exchange packets with its peers using > > the relay. TURN differs from some other relay control protocols in > > that it allows a client to communicate with multiple peers using a > > single relay address. > > > > The TURN protocol was designed to be used as part of the ICE > > (Interactive Connectivity Establishment) approach to NAT traversal, > > though it also can be used without ICE. > > > > This document obsoletes [RFC5766] and [RFC6156]. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-12 > > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-12 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-12 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 >=20 > -- > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. --_002_DM5PR16MB1788DADED96D6137E0F8B93DEAF20DM5PR16MB1788namp_ Content-Type: text/plain; name="turnbis-12_review_response.txt" Content-Description: turnbis-12_review_response.txt Content-Disposition: attachment; filename="turnbis-12_review_response.txt"; size=13491; creation-date="Fri, 09 Feb 2018 07:44:04 GMT"; modification-date="Fri, 09 Feb 2018 07:44:04 GMT" Content-Transfer-Encoding: base64 SGVhZGVyDQoNCkluZGljYXRlcyB0aGF0IGl0ICJVcGRhdGVzIiA1NzY2IGFuZCA2MTU2IGJ1dCBz dGF0ZXMgdGhhdCBpdCAiT2Jzb2xldGVzIiB0aGVtDQppbiB0aGUgYWJzdHJhY3QgdGV4dC4gU2hv dWxkIHN0YXRlICJPYnNvbGV0ZXMiIGluIHRoZSBoZWFkZXIuIEFsc28sIDYxNTYNCnNob3VsZCBi ZSBhIGxpbmssIGJ1dCBpdCBpcyBvbmx5IHRleHQuDQoNCltUUl0gUmVwbGFjZWQgIlVwZGF0ZXMi IHdpdGggIk9ic29sZXRlcyIgaW4gdGhlIGhlYWRlci4gDQoNCkFic3RyYWN0DQoNCk5JVDogU2hv dWxkIG5vdCBjb250YWluIHJlZmVyZW5jZXMuIFNob3VsZCBqdXN0IHByb3ZpZGUgdGV4dHVhbCBt ZW50aW9ucy4gVGhpcw0KaXMgZm9yIHRoZSByZWZlcmVuY2VzIGFkZGVkIHRvIGluZGljYXRlIHRo ZSBvYnNvbGV0ZWQgUkZDcy4gVGhvc2UgUkZDIG1lbnRpb25zDQpzaG91bGQgbm90IGV4cGFuZCB0 byBjbGlja2FibGUgbGlua3MgaW4gdGhlIEhUTUwgdmVyc2lvbi4NCg0KW1RSXSBJIGRpZCBub3Qg YWRkIGFueSByZWZlcmVuY2UsIHBsZWFzZSBjaGVjayB0aGUgeG1sIGZpbGUgDQoob3RoZXIgZHJh ZnRzIGxpa2Ugc3R1bmJpcyBhbHNvIGhhdmUgcmVmZXJlbmNlcyBpbiB0aGUgaGVhZGVyKS4NCg0K U3RhdHVzIG9mIFRoaXMgTWVtbw0KDQppZG5pdHMgdGhyb3dzIGEgd2FybmluZyBhYm91dCBCQ1A3 OCBhbmQgdGhlIGVhcmxpZXIgUkZDcyBvcmlnaW5hbGx5IGJlaW5nDQpwdWJsaXNoZWQgYXQgYSBw b2ludCBiZWZvcmUgQkNQNzgsIHN1Z2dlc3RpbmcgdGhhdCBpdCBtaWdodCBiZSBuZWNlc3Nhcnkg dG8NCmdldCB0aGUgYXV0aG9ycyB0byBhc3NpZ24gQkNQNzggcmlnaHRzLiBUaGlzIHNlZW1zIGNv bmZ1c2luZyB0byBtZSwgYmVjYXVzZQ0KdGhlIFJGQ3MgaW4gcXVlc3Rpb24gaGF2ZSBhbHJlYWR5 IGdpdmVuIEJDUDc4IHJpZ2h0cy4gSSdtIG5vdCBzdXJlIHdoZXRoZXINCmFkZGl0aW9uYWwgYXBw cm92YWxzIGFyZSByZXF1aXJlZCBoZXJlIG9yIG5vdC4NCg0KW1RSXSBPa2F5LCBSRkMgZWRpdG9y cyBjYW4gZmlndXJlIHRoaXMgb3V0LiANCg0KU2VjdGlvbiAxDQoNCk5JVDogbWlzcGxhY2VkIHNw YWNlDQoiY29ubmVjdG9uIHRvIHRoZSBJbnRlcm5ldCAuIEFzIGEgY29uc2VxdWVuY2UiDQoNCltU Ul0gRml4ZWQuDQoNClNlY3Rpb24gMi40DQoNCiJEYXRhIGluZGljYXRpb25zIGNvbnRhaW5pbmcg dGhlIFhPUi1QRUVSLUFERFJFU1MgYW5kIElDTVAgYXR0cmlidXRlIGFyZSBhbHNvDQpzZW50IHdo ZW4gdXNpbmcgdGhlIGNoYW5uZWwgbWVjaGFuaXNtLiINCkkgaGFkIHRvIHJlYWQgdGhhdCBhIGNv dXBsZSBvZiB0aW1lcyB0byBnZXQgdGhlIHBvaW50LiBJIHN1Z2dlc3Q6DQoiSUNNUCBhdHRyaWJ1 dGUgZm9yd2FyZGluZyBhbHdheXMgdXNlcyBEYXRhIGluZGljYXRpb25zIGNvbnRhaW5pbmcgdGhl DQpYT1ItUEVFUi1BRERSRVNTIGFuZCBJQ01QIGF0dHJpYnV0ZXMsIGV2ZW4gd2hlbiB1c2luZyB0 aGUgY2hhbm5lbCBtZWNoYW5pc20gdG8NCmZvcndhcmQgVURQIGRhdGEuIg0KDQpbVFJdIFVwZGF0 ZWQuIA0KDQpTZWN0aW9uIDIuNQ0KDQpOSVQ6IHJlbW92ZS9yZXBsYWNlIGJyYWNrZXRzIGFyb3Vu ZCBbMHg0MDAxXSwgc2luY2UgdGhleSBjb25mdXNlIGlkbml0cywNCm1ha2luZyBpdCB0aGluayB0 aGF0IDB4NDAwMSBpcyBhIHJlZmVyZW5jZS4NCg0KW1RSXSBEb25lLiANCg0KU2VjdGlvbiAyLjcN Cg0KInRoYXQgaXMgdXNpbmcgU1RVTiB0byBkaXNjb3ZlciB0aGUgUE1UVUQsIGFuZCBzbyBtYXkg YmUgYSBzdWl0YWJsZSBhcHByb2FjaA0KdG8gYmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIGEg VFVSTiBzZXJ2ZXIsIHRvZ2V0aGVyIHdpdGggdGhlIERPTlQtRlJBR01FTlQNCmF0dHJpYnV0ZS4i DQpJIGhhZCB0byByZWFkIHRoYXQgYSBjb3VwbGUgb2YgdGltZXMgdG8gZ2V0IHRoZSBwb2ludC4g SSBzdWdnZXN0Og0KInRoYXQgdXNlcyBTVFVOIHRvIGRpc2NvdmVyIHRoZSBwYXRoIE1UVSwgYW5k IHNvIG1pZ2h0IGJlIGEgc3VpdGFibGUgYXBwcm9hY2gNCnRvIGJlIHVzZWQgaW4gY29uanVuY3Rp b24gd2l0aCBhIFRVUk4gc2VydmVyIHRoYXQgc3VwcG9ydHMgdGhlIERPTlQtRlJBR01FTlQNCmF0 dHJpYnV0ZS4iDQoNCltUUl0gRml4ZWQuDQoNClNlY3Rpb24gMi45DQoNCiJ0aGUgc3ludGF4IG9m IHRoZSAidHVybiIgYW5kICJ0dXJuIiBVUklzIg0KVGhpcyBzaG91bGQgc2F5ICJ0dXJuIiBhbmQg InR1cm5zIiBJIHRoaW5rLg0KDQpbVFJdIEdvb2QgY2F0Y2gsIGZpeGVkLiANCg0KU2VjdGlvbiAy LjEwDQoNCkluIHRoZSBmaXJzdCBidWxsZXQsIGZvciBjbGFyaXR5LCBJIHN1Z2dlc3Q6DQoiRm9y IFRDUCBvciBUTFMtb3Zlci1UQ1AsIC4uLiINCg0KW1RSXSBVcGRhdGVkLg0KDQpOSVQ6IEluIHRo ZSB0aGlyZCBidWxsZXQsIGl0IHN0YXRlcyAib24gYm90aCBJUCBhZGRyZXNzZXMgZmFtaWxpZXMu IiBJIHRoaW5rDQp5b3Ugd2FudCAib24gYm90aCBJUCBhZGRyZXNzIGZhbWlsaWVzLiIgVGhpcyBj b3JyZWN0aW9uIGFwcGxpZXMgdHdpY2Ugd2l0aGluDQp0aGUgcGFyYWdyYXBoLg0KDQpbVFJdIEZp eGVkIGluIGJvdGggcGxhY2VzLg0KDQpTZWN0aW9uIDMNCg0KVGhpcyBpcyBhIGNhcnJ5IG92ZXIg Y29tbWVudCBmcm9tIFJGQzU3NjYuICBUaGUgZGVzY3JpcHRpb24gb2YgYSBOb25jZSBzYXlzDQoi VG8gcHJldmVudCByZXBseSBhdHRhY2tzLCAuLi4iLiBTaG91bGRuJ3QgdGhpcyBiZSAicmVwbGF5 IGF0dGFja3MiPw0KDQpbVFJdIFllcywgZml4ZWQuIA0KDQpTZWN0aW9uIDQNCg0KSW4gdGhlIHBh cmFncmFwaCB0aGF0IGludHJvZHVjZXMgQURESVRJT05BTC1BRERSRVNTLUZBTUlMWSwgaXQgbWln aHQgYmUgZ29vZA0KdG8gaW50cm9kdWNlIHRoZSByZWxhdGVkIHJlc3RyaWN0aW9uIG9uIHVzZSBv ZiB0aGUgRVZFTi1QT1JUIGF0dHJpYnV0ZSBhbmQNCmV4cGxhaW4gdGhlIHJlYXNvbiBmb3IgaXQu IFdoZW4gdGhpcyBpcyBtZW50aW9uZWQgaW4gc2VjdGlvbiA2LjEsIGl0J3Mgbm90DQpjbGVhciB3 aHkgdGhpcyByZXN0cmljdGlvbiBpcyB0aGVyZS4gU2VjdGlvbiA0IHNlZW1zIGxpa2UgdGhlIGJl dHRlciBwbGFjZSB0bw0KZXhwbGFpbiB0byBtZSwgYnV0IGl0IHdvdWxkIGJlIE9LIGluIHNlY3Rp b24gNi4xIGluc3RlYWQuDQoNCltUUl0gU2VjdGlvbiA0IGlzIG9ubHkgZGlzY3Vzc2luZyB0aGUg Z2VuZXJhbCBiZWhhdmlvdXIgYW5kIEkgZG9uJ3QgdGhpbmsgcmVzdHJpY3Rpb25zIG9uIHRoZSB1 c2UNCm9mIEVWRU4tUE9SVCBhdHRyaWJ1dGUgc2hvdWxkIGJlIG1vdmVkIGZyb20gU2VjdGlvbiA2 LjEgdG8gU2VjdGlvbiA0Lg0KDQpTZWN0aW9uIDUNCg0KVGhlIG9sZCB0ZXh0IHN0YXRlczogIkJv dGggdGhlIHJlbGF5ZWQgdHJhbnNwb3J0IGFkZHJlc3MgYW5kIHRoZSA1LXR1cGxlIE1VU1QNCmJl IHVuaXF1ZSBhY3Jvc3MgYWxsIGFsbG9jYXRpb25zLCBzbyBlaXRoZXIgb25lIGNhbiAuLi4iLiBU aGUgbmV3IHRleHQgcmVtb3Zlcw0KdGhlIHJlZmVyZW5jZSB0byB0aGUgNS10dXBsZSBpbiB0aGlz IHNlbnRlbmNlLiBJIGNhbid0IHJlbWVtYmVyIHdoeSB0aGlzDQpjaGFuZ2Ugd2FzIG1hZGUuIFdv dWxkIHlvdSByZW1pbmQgbWUgcGxlYXNlLiANCg0KW1RSXSBXaXRoIHRoZSBkdWFsIGFsbG9jYXRp b24sIHRoZSA1LXR1cGxlIG5vIGxvbmdlciB1bmlxdWVseSBpZGVudGlmZXMgYW4gYWxsb2NhdGlv bi4NCg0KQWxzbywgaWYgdGhlIDUtdHVwbGUgaXMgbm8gbG9uZ2VyDQpleHBlY3RlZCB0byBiZSBh IHVuaXF1ZSBrZXksIGl0IHdvdWxkIGJlIGdvb2QgZm9yIHRoaXMgdGV4dCB0byBzdGF0ZSB3aGF0 IHRoZQ0KdW5pcXVlIGtleSBpcyAoaS5lLiB3aGF0IGlzIGFkZGVkIHRvIHRoZSA1LXR1cGxlIHRv IGdldCB1bmlxdWVuZXNzKS4NCg0KW1RSXSA1LXR1cGxlIHdpbGwgZWl0aGVyIGlkZW50aWZ5IGEg c2luZ2xlIG9yIGR1YWwgYWxsb2NhdGlvbi4gDQoNCk5JVDogIndoaWNoIGlzIGFuIHNlY3VyZSBo YXNoIiBzaG91bGQgYmUgIndoaWNoIGlzIGEgc2VjdXJlIGhhc2giDQoNCltUUl0gRml4ZWQuIA0K DQpTZWN0aW9uIDYuMQ0KDQoiVGhlIGNsaWVudCB1c2VzIHRoZSBwcm9jZWR1cmVzIGRlc2NyaWJl ZCBpbiBbUkZDODE1NV0gdG8gZGlzY292ZXIgYSBUVVJODQpzZXJ2ZXIgYW5kIFRVUk4gc2VydmVy IHJlc29sdXRpb24gbWVjaGFuaXNtIGRlZmluZWQgaW4gW1JGQzU5MjhdIHRvIGdldCBhIGxpc3QN Cm9mIHNlcnZlciB0cmFuc3BvcnQgYWRkcmVzc2VzIC4uLiINCkkgaGFkIHRvIHJlYWQgdGhhdCBh IGNvdXBsZSB0aW1lcyB0byBnZXQgdGhlIHBvaW50LiBJIHN1Z2dlc3Q6DQoiVGhlIGNsaWVudCB1 c2VzIG9uZSBvZiB0aGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gW1JGQzgxNTVdIHRvIGRpc2Nv dmVyIGENClRVUk4gc2VydmVyIGFuZCB1c2VzIHRoZSBUVVJOIHNlcnZlciByZXNvbHV0aW9uIG1l Y2hhbmlzbSBkZWZpbmVkIGluIFtSRkM1OTI4XQ0KdG8gZ2V0IGEgbGlzdCBvZiBzZXJ2ZXIgdHJh bnNwb3J0IGFkZHJlc3NlcyAuLi4iDQoNCltUUl0gVGhlIGNsaWVudCBjYW4gdXNlIG9uZSBvciBt b3JlIHByb2NlZHVyZXMgZGVzY3JpYmVkIGluIFJGQzgxNTUuIEkgaGF2ZSB1cGRhdGVkDQp0aGUg YWJvdmUgdGV4dCBhcyBmb2xsb3dzOg0KIlRoZSBjbGllbnQgdXNlcyBvbmUgb3IgbW9yZSBwcm9j ZWR1cmVzIGRlc2NyaWJlZCBpbiBbUkZDODE1NV0gdG8gZGlzY292ZXIgYQ0KVFVSTiBzZXJ2ZXIg YW5kIHVzZXMgdGhlIFRVUk4gc2VydmVyIHJlc29sdXRpb24gbWVjaGFuaXNtIGRlZmluZWQgaW4g W1JGQzU5MjhdDQp0byBnZXQgYSBsaXN0IG9mIHNlcnZlciB0cmFuc3BvcnQgYWRkcmVzc2VzIC4u LiINCg0KTklUOiAiSWYgdGhlIGNsaWVudCB3aGlzaGVzIHRvIG9idGFpbiBvbmUgSVB2NiBhbmQg b25lIElQdjQgcmVsYXllZCB0cmFuc3BvcnQNCmFkZHJlc3NlcyAuLi4iLiBUaGF0IHNob3VsZCBi ZSAiYWRkcmVzcyIsIG5vdCAiYWRkcmVzc2VzIi4NCg0KW1RSXSBGaXhlZA0KDQpTZWN0aW9uIDYu Mg0KDQpidWxsZXQgIzYNCiJUaGUgc2VydmVyIGNoZWNrcyBpZiB0aGUgcmVxdWVzdCBjb250YWlu cyBib3RoIFJFUVVFU1RFRC1BRERSRVNTLUZBTUlMWSBhbmQNCkFERElUSU9OQUwtQUREUkVTUy1G QU1JTFkgYXR0cmlidXRlcywgdGhlbiB0aGUgc2VydmVyIHJlamVjdHMgLi4uIg0KVXNlIG9mICJ0 aGVuIiBoZXJlIGlzIGluY29ycmVjdC4gSSBzdWdnZXN0Og0KIlRoZSBzZXJ2ZXIgY2hlY2tzIGlm IHRoZSByZXF1ZXN0IGNvbnRhaW5zIGJvdGggUkVRVUVTVEVELUFERFJFU1MtRkFNSUxZIGFuZA0K QURESVRJT05BTC1BRERSRVNTLUZBTUlMWSBhdHRyaWJ1dGVzLiBJZiB5ZXMsIHRoZW4gdGhlIHNl cnZlciByZWplY3RzIC4uLiINCg0KW1RSXSBVcGRhdGVkLg0KDQpidWxsZXQgIzcNCkFyZSBhbGwg VFVSTiBzZXJ2ZXJzIHJlcXVpcmVkIHRvIHN1cHBvcnQgSVB2NCByZWxheWVkIHRyYW5zcG9ydCBh ZGRyZXNzZXM/IElmDQpub3QsIHRoZW4gdGhpcyBidWxsZXQgc2hvdWxkIGluZGljYXRlIHRoYXQg NDQwIE1VU1QgYmUgcmV0dXJuZWQgaWYgdGhlcmUgaXMgbm8NClJFUVVFU1RFRC1BRERSRVNTLUZB TUlMWSBhdHRyaWJ1dGUgYW5kIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBJUHY0Lg0KDQpb VFJdIEdvb2QgcG9pbnQsIHVwZGF0ZWQgZHJhZnQgYXMgZm9sbG93cy4gDQpORVc6DQogSWYgdGhl IFJFUVVFU1RFRC1BRERSRVNTLUZBTUlMWSBhdHRyaWJ1dGUgaXMgYWJzZW50IGFuZCB0aGUgc2Vy dmVyIGRvZXMgbm90IHN1cHBvcnQgSVB2NCBhZGRyZXNzIGZhbWlseSwgDQogdGhlIHNlcnZlciBN VVNUIGluY2x1ZGUgYW4gRVJST1ItQ09ERSBhdHRyaWJ1dGUgd2l0aCB0aGUgNDQwIChBZGRyZXNz IEZhbWlseSBub3QgU3VwcG9ydGVkKSByZXNwb25zZSBjb2RlLiANCiBJZiB0aGUgUkVRVUVTVEVE LUFERFJFU1MtRkFNSUxZIGF0dHJpYnV0ZSBpcyBhYnNlbnQgYW5kIHRoZSBzZXJ2ZXIgc3VwcG9y dHMgSVB2NCBhZGRyZXNzIGZhbWlseSwgDQogdGhlIHNlcnZlciBNVVNUIGFsbG9jYXRlIGFuIElQ djQgcmVsYXllZCB0cmFuc3BvcnQgYWRkcmVzcyBmb3IgdGhlIFRVUk4gY2xpZW50Lg0KDQpidWxs ZXQgIzkNCk5JVDogIk90aGVyd2lzZSwgYW5kIHRoZSBzZXJ2ZXIgY2hlY2tzIC4uLiIuIFRoaXMg c2hvdWxkIGJlICJPdGhlcndpc2UsIHRoZQ0Kc2VydmVyIGNoZWNrcyAuLi4iLg0KDQpbVFJdIEZp eGVkLiANCg0KIklmIGFsbCB0aGUgY2hlY2tzIHBhc3MsIHRoZSBzZXJ2ZXIgY3JlYXRlcyBlaXRo ZXIgdGhlIHNpbmdsZSBvciBkdWFsDQphbGxvY2F0aW9uLiIgSSBkb24ndCB0aGluayBpdCdzIG5l Y2Vzc2FyeSBvciBoZWxwIHRvIGluZGljYXRlICJlaXRoZXIgdGhlDQpzaW5nbGUgb3IgZHVhbCBh bGxvY2F0aW9uIiBoZXJlLiBJIHdvdWxkIGp1c3Qgc3RhdGUgImNyZWF0ZXMgdGhlIGFsbG9jYXRp b24iLg0KRHVlIHRvIGRpZmZlcmVuY2VzIGluIGV4cGlyYXRpb24gdGltZXMsIGEgZHVhbCBhbGxv Y2F0aW9uIGNvdWxkIGJlY29tZSBhDQpzaW5nbGUgYWxsb2NhdGlvbiBsYXRlciwgc28gaW4gbXkg b3BpbmlvbiBpdCdzIGEgZmFsc2UgZGlzdGluY3Rpb24gdG8gcmVmZXIgdG8NCnRoZW0gYXMgaWYg dGhleSBhcmUgZGlmZmVyZW50IHRoaW5ncy4NCg0KW1RSXSBPa2F5LCB1cGRhdGVkLiANCg0KTklU OiAiLi4uIHNlY3Rpb24gNi4zLjEgb2YgW0ktRC5pZXRmLXRyYW0tc3R1bmJpc10gcmVxdWlyZXMg Li4uIi4gSSB3b3VsZCBub3QNCnJlZmVyIHRvIHNwZWNpZmljIHNlY3Rpb24gbnVtYmVycyBpbiBh biBleHRlcm5hbCBhcy15ZXQtdW5wdWJsaXNoZWQgZHJhZnQsDQpzaW5jZSBpdCdzIGFsd2F5cyBw b3NzaWJsZSB0aGF0IHRoaXMgc2VjdGlvbiBudW1iZXIgd2lsbCBjaGFuZ2UuIEkgd291bGQganVz dA0Kc3RhdGUgdGhhdCBzdHVuYmlzIHJlcXVpcmVzIHRoaXMuDQoNCltUUl0gRG9uZS4gDQoNClNl Y3Rpb24gNi4zDQoNClRoZSBwcmV2aW91cyBzZWN0aW9uLCA2LjIsIGFsbG93cyBmb3IgYW4gQURE UkVTUy1FUlJPUi1DT0RFIGF0dHJpYnV0ZSBpbiBhbg0KYWxsb2NhdGUgc3VjY2VzcyByZXNwb25z ZS4gVGhpcyBzZWN0aW9uLCA2LjMsIGRvZXMgbm90IGRlc2NyaWJlIGhvdyB0aGUgY2xpZW50DQpp cyBleHBlY3RlZCB0byBoYW5kbGUgdGhpcyBhdHRyaWJ1dGUuDQoNCltUUl0gR29vZCBwb2ludCwg YWRkZWQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggdG8gc2VjdGlvbiA2LjI6DQoNCklmIHRoZSBj bGllbnQgcmVjZWl2ZXMgYW4gQWxsb2NhdGUgc3VjY2VzcyByZXNwb25zZSBidXQgd2l0aCBBRERS RVNTLUVSUk9SLUNPREUgYXR0cmlidXRlIGluIHRoZSByZXNwb25zZSBhbmQgdGhlIA0KZXJyb3Ig Y29kZSB2YWx1ZSBzaWduYWxlZCBpbiB0aGUgQUREUkVTUy1FUlJPUi1DT0RFIGF0dHJpYnV0ZSBp cyA0NDAgKEFkZHJlc3MgRmFtaWx5IG5vdCBTdXBwb3J0ZWQpLCB0aGUgY2xpZW50IA0KTVVTVCBO T1QgcmV0cnkgaXRzIHJlcXVlc3QgZm9yIHRoZSByZWplY3RlZCBhZGRyZXNzIHR5cGUuIElmIHRo ZSBjbGllbnQgcmVjZWl2ZXMgYW4gQUREUkVTUy1FUlJPUi1DT0RFIGF0dHJpYnV0ZSANCmluIHRo ZSByZXNwb25zZSBhbmQgdGhlIGVycm9yIGNvZGUgdmFsdWUgc2lnbmFsZWQgaW4gdGhlIEFERFJF U1MtRVJST1ItQ09ERSBhdHRyaWJ1dGUgaXMgNTA4IChJbnN1ZmZpY2llbnQgQ2FwYWNpdHkpLCAN CnRoZSBjbGllbnQgU0hPVUxEIHdhaXQgYXQgbGVhc3QgMSBtaW51dGUgYmVmb3JlIHRyeWluZyB0 byByZXF1ZXN0IGFueSBtb3JlIGFsbG9jYXRpb25zIG9uIHRoaXMgc2VydmVyIGZvciB0aGUgDQpy ZWplY3RlZCBhZGRyZXNzIHR5cGUuIA0KDQpTZWN0aW9uIDcuMg0KDQpOSVQ6ICIuLi4gaXQgcHJv Y2Vzc2VzIGl0IC4uLiIuIEkgc3VnZ2VzdCBpbnN0ZWFkICIuLi4gaXQgcHJvY2Vzc2VzIHRoZQ0K cmVxdWVzdCAuLi4iIHRvIGF2b2lkIHVzZSBvZiB0aGUgc2FtZSBwcm9ub3VuIHRvIHJlZmVyIHRv IHR3byBkaWZmZXJlbnQNCnRoaW5ncy4NCg0KW1RSXSBGaXhlZC4gDQoNCk5JVDogIiAuLi4gYW4g UkVRVUVTVEVELUFERFJFU1MtRkFNSUxZIC4uLiIsIHNob3VsZCBiZSAiYSIsIG5vdCAiYW4iLg0K DQpbVFJdIEZpeGVkLiANCg0KU2VjdGlvbiA5LjENCg0KTklUOiBJIHdvdWxkIHVzZSBub3JtYXRp dmUgdGV4dCBpbiBhIGNvdXBsZSBwbGFjZXMgaGVyZS4gIi4uLiBhdHRyaWJ1dGVzIE1BWQ0KYXBw ZWFyIGluIGFueSBvcmRlci4iICIuLi4gdGhlIGNsaWVudCBNQVkgaW5jbHVkZSAuLi4iDQoNCltU Ul0gRml4ZWQuDQoNClNlY3Rpb24gOS4yDQoNCk5JVDogIi4uLiBub3QgdGhlIHNhbWUgYXMgdGhh dCBvZiB0aGUgcmVsYXllZCB0cmFuc3BvcnQgYWRkcmVzcyAuLi4iLiBJIHdvdWxkDQp1c2UgImEg cmVsYXllZCIsIG5vdCAidGhlIHJlbGF5ZWQiLCBzaW5jZSB0aGVyZSBjYW4gYmUgbXVsdGlwbGUu DQoNCltUUl0gRml4ZWQuDQoNClNlY3Rpb24gMTAuNCBhbmQgMTAuNg0KDQpBIERhdGEgaW5kaWNh dGlvbiBpcyByZXF1aXJlZCB0byBjb250YWluIGVpdGhlciBhIERBVEEgYXR0cmlidXRlIG9yIGFu IElDTVANCmF0dHJpYnV0ZSwgcmlnaHQ/IA0KDQpbVFJdIFllcy4gDQoNClRoZXJlIHNob3VsZCBi ZSBzb21lIHRleHQgaW4gdGhlIGRvYyAocHJvYmFibHkgc2VjdGlvbiAxMC40KQ0KdGhhdCBpbmRp Y2F0ZXMgdGhpcy4gSSB3b3VsZCByZW1vdmUgIndpdGggREFUQSBhdHRyaWJ1dGUiIGZyb20gdGhl IHRpdGxlIG9mDQpzZWN0aW9uIDEwLjQgYW5kIG1vdmUgdGhlIGxhc3Qgc2VudGVuY2Ugb2YgcGFy YWdyYXBoIG9uZSBpbnRvIHRoZSBmb2xsb3dpbmcNCnBhcmFncmFwaCB0byBiZSBpbnNlcnRlZCBh ZnRlciB0aGUgTk9URS4NCg0KICBJZiB0aGUgWE9SLVBFRVItQUREUkVTUyBpcyBwcmVzZW50IGFu ZCB2YWxpZCwgdGhlIGNsaWVudCBjaGVja3MgdGhhdCB0aGUNCiAgRGF0YSBpbmRpY2F0aW9uIGNv bnRhaW5zIGVpdGhlciBhIERBVEEgYXR0cmlidXRlIG9yIGFuIElDTVAgYXR0cmlidXRlIGFuZA0K ICBkaXNjYXJkcyB0aGUgaW5kaWNhdGlvbiBpZiBpdCBkb2VzIG5vdC4gTm90ZSB0aGF0IGEgREFU QSBhdHRyaWJ1dGUgaXMNCiAgYWxsb3dlZCB0byBjb250YWluIHplcm8gYnl0ZXMgb2YgZGF0YS4g UHJvY2Vzc2luZyBvZiBEYXRhIGluZGljYXRpb25zIHdpdGgNCiAgSUNNUCBhdHRyaWJ1dGVzIGlz IGRlc2NyaWJlZCBpbiBzZWN0aW9uIDEwLjYgYmVsb3cuDQoNCltUUl0gVXBkYXRlZCBzZWN0aW9u IDEwLjQuIA0KDQpTZWN0aW9uIDExLjENCg0KTklUOiAiLi4uIGFzIHRoYXQgb2YgdGhlIHJlbGF5 ZWQgdHJhbnNwb3J0IGFkZHJlc3MgLi4uIi4gSSB3b3VsZCB1c2UgImENCnJlbGF5ZWQiLCBub3Qg InRoZSByZWxheWVkIiwgc2luY2UgdGhlcmUgY2FuIGJlIG11bHRpcGxlLg0KDQpbVFJdIEZpeGVk Lg0KDQpTZWN0aW9uIDExLjINCg0KTklUOiAiLi4uIG5vdCB0aGUgc2FtZSBhcyB0aGF0IG9mIHRo ZSByZWxheWVkIHRyYW5zcG9ydCBhZGRyZXNzIC4uLiIuIEkgd291bGQNCnVzZSAiYSByZWxheWVk Iiwgbm90ICJ0aGUgcmVsYXllZCIsIHNpbmNlIHRoZXJlIGNhbiBiZSBtdWx0aXBsZS4NCg0KW1RS XSBGaXhlZC4gDQoNClNlY3Rpb24gMTEuNw0KDQpOSVQ6ICIuLi4gc2VudCByZWdhcmRsZXNzIGlm IHRoZXJlIGlzIGEgY2hhbm5lbCBib3VuZCAuLi4iLiBJIHN1Z2dlc3QgIi4uLg0Kc2VudCByZWdh cmRsZXNzIG9mIHdoZXRoZXIgdGhlcmUgaXMgYSBjaGFubmVsIGJvdW5kIC4uLiIuDQoNCltUUl0g Rml4ZWQuIA0KDQpTZWN0aW9uIDEyDQoNClRoZSBzZWN0aW9uIGZyb20gUkZDNjE1NiBpcyBtb3Jl IGNsZWFyIGFib3V0IHdoYXQgc3BlY2lmaWNhbGx5IGlzIGRlc2NyaWJlZCBpbg0KdGhlIHNlY3Rp b24gdGhhbiB0aGlzIHNlY3Rpb24uIEkgc3VnZ2VzdCB0aGF0IHlvdSBhZGQgdGhpcyBpbnRyb2R1 Y3RvcnkNCnBhcmFncmFwaCB0byB0aGUgc2VjdGlvbi4gVGhlIHRleHQgaXMgbW9zdGx5IGNhcnJp ZWQgb3ZlciBmcm9tIFJGQzYxNTYuDQoNCiAgVGhpcyBzZWN0aW9uIGFkZHJlc3NlcyBJUHY0LXRv LUlQdjYsIElQdjYtdG8tSVB2NCwgYW5kIElQdjYtdG8tSVB2Ng0KICB0cmFuc2xhdGlvbnMuIFJl cXVpcmVtZW50cyBmb3IgdHJhbnNsYXRpb24gb2YgdGhlIElQIGFkZHJlc3NlcyBhbmQgcG9ydA0K ICBudW1iZXJzIG9mIHRoZSBwYWNrZXRzIGFyZSBkZXNjcmliZWQgYWJvdmUuIFRoZSBmb2xsb3dp bmcgc2VjdGlvbnMgc3BlY2lmeQ0KICBob3cgdG8gdHJhbnNsYXRlIG90aGVyIGhlYWRlciBmaWVs ZHMuDQoNCltUUl0gQWRkZWQgYWJvdmUgcGFyYWdyYXBoLg0KDQpUaGUgUkZDIHJlZmVyZW5jZXMg aW4gdGhpcyBzZWN0aW9uIGhhdmUgY2hhbmdlZCwgd2l0aCB0aGUgcmVmZXJlbmNlcyBmcm9tDQpS RkM2MTU2IG5vdyBoYXZpbmcgYmVlbiBvYnNvbGV0ZWQuIEhhcyB0aGlzIHNlY3Rpb24gdW5kZXJn b25lIGFub3RoZXIgZXhwZXJ0DQpyZXZpZXcgZnJvbSBzb21lb25lIGluIHY2b3BzIHRvIHZlcmlm eSB0aGF0IG5vbmUgb2YgdGhlIHJlc3Qgb2YgdGhlIHRleHQNCnNob3VsZCBiZSB1cGRhdGVkPyBJ IGV4cGVjdCB0aGF0IHRoZSBSRkM2MTU2IHRleHQgc3RpbGwgc3RhbmRzLCBidXQgaXQgbWlnaHQN CmJlIHdvcnRoIHZlcmlmaWNhdGlvbi4NCg0KU2VjdGlvbiAxMi4xDQoNCk5JVDogQSByZWZlcmVu Y2UgdG8gUkZDNjQzNyBkb2VzIG5vdCBleHBhbmQgdG8gYSBjbGlja2FibGUgbGluay4NCg0KTklU OiAidGhlIHJlbGF5IHNldHMgdGhlIEZsb3cgbGFiZWwgLi4uIi4gRml4IGNhc2U6ICJUaGUgcmVs YXkgc2V0cyAuLi4iDQoNCltUUl0gRml4ZWQuIA0KDQpTZWN0aW9uIDEyLjINCg0KTklUOiBBIHJl ZmVyZW5jZSB0byBSRkM2NDM3IGRvZXMgbm90IGV4cGFuZCB0byBhIGNsaWNrYWJsZSBsaW5rLg0K DQpbVFJdIEZpeGVkLiANCg0KU2VjdGlvbiAxMi4zDQoNCk5JVDogTWlzcGxhY2VkIHNwYWNlLiAi IEFkZGl0aW9uYWxseSwgd2hlbiB0aGUgb3V0Z29pbmcgLi4uIiBJbmRlbnRhdGlvbiBvZg0KdGhp cyBsaW5lIGxvb2tzIHdyb25nLg0KDQpbVFJdIEZpeGVkLiANCg0KU2VjdGlvbiAxNS42DQoNClRo ZSBmaXJzdCBzZW50ZW5jZSBzdGF0ZXMgIi4uLiB0aGUgYWxsb2NhdGlvbiBvZiBhIHNwZWNpZmlj IGFkZHJlc3MgdHlwZSAuLi4iLg0KSXQgc2hvdWxkIHByb2JhYmx5IHN0YXRlICIuLi4gdGhlIGFs bG9jYXRpb24gb3IgcmVmcmVzaCBvZiBhIHNwZWNpZmljIGFkZHJlc3MNCnR5cGUgLi4uIi4NCg0K W1RSXSBVcGRhdGVkLiANCg0KVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBvZiB0ZXh0IGNvcGllZCBm cm9tIFJGQzYxNTYgYXJlIHByb2JhYmx5IG5vdCBuZWNlc3NhcnkNCmluIHRoaXMgc2VjdGlvbiBh Ym91dCBSRVFVRVNURUQtQUREUkVTUy1GQU1JTFksIHNpbmNlIHRoZXkgaGF2ZSBhbHJlYWR5IGJl ZW4NCmNvdmVyZWQgYXQgYSBnZW5lcmFsIGxldmVsIGVsc2V3aGVyZS4NCg0KICBOb3RlIHRoYXQg VFVSTiBhdHRyaWJ1dGVzIGFyZSBUTFYgKFR5cGUtTGVuZ3RoLVZhbHVlKSBlbmNvZGVkLCB3aXRo IGENCiAgMTYtYml0IHR5cGUsIGEgMTYtYml0IGxlbmd0aCwgYW5kIGEgdmFyaWFibGUtbGVuZ3Ro IHZhbHVlLg0KDQpbVFJdIFJlbW92ZWQuDQoNCiAgQXMgc3BlY2lmaWVkIGluIFtJLUQuaWV0Zi10 cmFtLXN0dW5iaXNdLCBhdHRyaWJ1dGVzIHdpdGggdmFsdWVzIGJldHdlZW4NCiAgMHgwMDAwIGFu ZCAweDdGRkYgYXJlIGNvbXByZWhlbnNpb24tcmVxdWlyZWQsIHdoaWNoIG1lYW5zIHRoYXQgdGhl IGNsaWVudCBvcg0KICBzZXJ2ZXIgY2Fubm90IHN1Y2Nlc3NmdWxseSBwcm9jZXNzIHRoZSBtZXNz YWdlIHVubGVzcyBpdCB1bmRlcnN0YW5kIHRoZQ0KICBhdHRyaWJ1dGUuDQoNCltUUl0gUmVtb3Zl ZC4NCg0KQ29uc2lkZXJpbmcgdGhhdCB0aGUgb3RoZXIgYXR0cmlidXRlcyBpbiB0aGlzIHNlY3Rp b24gZG9uJ3QgaW5jbHVkZSB0aGUgVHlwZQ0KYW5kIExlbmd0aCBwYXJ0cyBvZiB0aGUgYXR0cmli dXRlIGZvcm1hdCwgdGhpcyBvbmUgc2hvdWxkIHByb2JhYmx5IG5vdCBpbmNsdWRlDQp0aGVtIGVp dGhlciwgc28gcmVtb3ZpbmcgdGhlbSBmcm9tIGJvdGggdGhlIGRpYWdyYW0gYW5kIHRoZSBkZXNj cmlwdGlvbiBtYWtlcw0Kc2Vuc2UuIEluc3RlYWQsIHRoaXMgc2VjdGlvbiBjYW4gc2ltcGx5IHN0 YXRlOg0KDQogIFRoZSB2YWx1ZSBpcyA0IGJ5dGVzIHdpdGggdGhlIGZvbGxvd2luZyBmb3JtYXQ6 DQoNClRoaXMgd291bGQgYmUgaW4gbGluZSB3aXRoIHdoYXQgb3RoZXIgc3VjaCBzZWN0aW9uc2lu IHRoZSBJLUQgZG8uDQoNCltUUl0gQWdyZWVkLCB1cGRhdGVkIHNlY3Rpb24uIA0KDQpUaGUgbGFz dCBzZW50ZW5jZSBpbiB0aGlzIHNlY3Rpb24gbG9va3Mgd3JvbmcgdG8gbWUsIGFuZCBJIGRvbid0 IHRoaW5rIHRoYXQNCnN1Y2ggbm9ybWF0aXZlIHRleHQgaXMgcmVxdWlyZWQgaW4gdGhpcyBzZWN0 aW9uLiBJIHN1Z2dlc3QgdGhhdCB5b3UgcmVtb3ZlDQp0aGF0IHNlbnRlbmNlLg0KDQogIFRoZSBS RVFVRVNURUQtQUREUkVTUy1UWVBFIGF0dHJpYnV0ZSBNQVkgb25seSBiZSBwcmVzZW50IGluIEFs bG9jYXRlDQogIHJlcXVlc3RzLg0KDQpbVFJdIEkgaGF2ZSBwaWNrZWQgdGhlIGFib3ZlIGxpbmUg ZnJvbSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE1NiNzZWN0aW9uLTQuMS4xLg0K DQpTZWN0aW9uIDE1LjEyDQoNClRoaXMgc2VjdGlvbiBhbHNvIGRvZXMgbm90IG5lZWQgdG8gaW5j bHVkZSBUeXBlIGFuZCBMZW5ndGggaW4gZWl0aGVyIHRoZQ0KZGlhZ3JhbSBvciB0aGUgZGVzY3Jp cHRpb25zLiBJbnN0ZWFkLCBpdCBjYW4gc2ltcGx5IHN0YXRlOg0KDQogIFRoZSB2YWx1ZSBwb3J0 aW9uIG9mIHRoaXMgYXR0cmlidXRlIGlzIHZhcmlhYmxlIGxlbmd0aC4NCg0KW1RSXSBTdXJlLCB1 cGRhdGVkIHNlY3Rpb24uDQoNClRoZSBsYXN0IHNlbnRlbmNlIGluIHRoaXMgc2VjdGlvbiBkb2Vz IG5vdCBhcHBlYXIgbmVjZXNzYXJ5IHRvIG1lLCBhbmQgdGhlDQpub3JtYXRpdmUgdGV4dCBpbiBp dHMgY3VycmVudCBmb3JtIGlzIGNvbmZ1c2luZy4gSSBzdWdnZXN0IHJlbW92aW5nIGl0DQplbnRp cmVseS4NCg0KICBUaGUgQUREUkVTUy1FUlJPUi1DT0RFIGF0dHJpYnV0ZSBNQVkgb25seSBiZSBw cmVzZW50IGluIEFsbG9jYXRlIHJlc3BvbnNlcy4NCg0KW1RSXSBSRkM2MTU2IGhhcyBhIHNpbWls YXIgbGluZSBpbiB0aGUgc2VjdGlvbiB3aGVyZSBhIGF0dHJpYnV0ZSBpcyBkZWZpbmVkLg0KDQpT ZWN0aW9uIDE4LjQNCg0KUGxlYXNlIGRvdWJsZS1jaGVjayB0aGUgdXNlIG9mIGFkZHJlc3NlcyBp biB0aGUgZXhhbXBsZSB0ZXh0IHRvIGVuc3VyZSB0aGF0IGl0DQpjb21wbGllcyB3aXRoIHRoZSBJ UHY2IGRvY3VtZW50YXRpb24gYWRkcmVzcyByYW5nZS4NCg0KW1RSXSBZZXMsIGl0IGNvbXBsaWVz IHdpdGggdGhlIElQdjYgZG9jdW1lbnRhdGlvbiBhZGRyZXNzIHJhbmdlIHNwZWNpZmllZCBpbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzg0OS4NCg0K --_002_DM5PR16MB1788DADED96D6137E0F8B93DEAF20DM5PR16MB1788namp_-- From nobody Fri Feb 9 03:53:52 2018 Return-Path: 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 4C654127342 for ; Fri, 9 Feb 2018 03:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 iLVMPcJf41Oi for ; Fri, 9 Feb 2018 03:53:49 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174F8126BF0 for ; Fri, 9 Feb 2018 03:53:48 -0800 (PST) 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=1518177228; h=From: To: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-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: 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-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=q1MZqOXvJoVzkONfQQJuiUIySxJi1Y/3OBaYzG 4Gnik=; b=lAWMwrhO8sjX2vUCHrKOTpvGiomE8CB3HaS1X5k7 qTYaq8x65MP8JN6taSWMvO3TkGjnWDFhJQAnY94mcK4LSaGO4o kpaae1xyOcm4Wm+goo9eU+igKwLi8ONzhT9OTuFGBn41mVe3vC 7oDLA5X8Q6A233N13iA6q9UTeA1+NFQ= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 63fe_8aa2_00902436_efdb_4fc1_be61_13a44e586b24; Fri, 09 Feb 2018 05:53:47 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 04:53:46 -0700 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 04:53:46 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 9 Feb 2018 04:53:46 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 04:53:45 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB0059.namprd16.prod.outlook.com (10.172.92.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 9 Feb 2018 11:53:44 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0464.017; Fri, 9 Feb 2018 11:53:44 +0000 From: "Konda, Tirumaleswar Reddy" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] Review of TURNbis-11 Thread-Index: AQHTS1VEMV/cplA80E+CbiTeE9FOmaOcXoOg Date: Fri, 9 Feb 2018 11:53:44 +0000 Message-ID: References: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> In-Reply-To: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB0059; 7:IioKJhSQ5+h3Xz1cUpra6eUgbu8Peb14GZqHtn/N5cYP5L59D19RB8xHTzR3/jnAIoGqKcnF7D93pUcoe7Nk5zp0P2+9rNVrl3KOZRCneeY1kEcH7cX1oYcmMPjV2tLFqkKgOKlvhNNkxuDqKOd+aTz2GtBIFRv9U0VVnaAU4y1fjWEr6pyRvbkpHSHl1W2qC8w4zUPTgxNq5xeUbJeCHYlAxO1tl97JIRIqC9mJLr26X+VxmhE78HZRnLZZ0bCV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f3b28183-28a1-429e-7d54-08d56fb3c55c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB0059; x-ms-traffictypediagnostic: DM5PR16MB0059: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089)(128460861657000)(81160342030619); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(6041288)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR16MB0059; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB0059; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(39380400002)(366004)(396003)(346002)(252514010)(51444003)(32952001)(13464003)(199004)(189003)(102836004)(26005)(77096007)(74316002)(3660700001)(305945005)(7736002)(53936002)(316002)(59450400001)(76176011)(53546011)(110136005)(3846002)(6116002)(106356001)(6246003)(33656002)(66066001)(3280700002)(6506007)(5660300001)(86362001)(186003)(99286004)(7696005)(14454004)(45080400002)(478600001)(97736004)(72206003)(80792005)(966005)(2950100002)(2900100001)(2906002)(6436002)(2501003)(105586002)(68736007)(25786009)(55016002)(6306002)(9686003)(229853002)(81166006)(8676002)(81156014)(8936002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB0059; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LBJe3yxX7/3TKvAzNVwvp1rK+fb3WJivqPZfed2iCcqwc6wlURMEO26+rg/QFZD7WuzFHsbgX6pxlN4wr2ZSnQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f3b28183-28a1-429e-7d54-08d56fb3c55c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 11:53:44.2545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB0059 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 <6218> : inlines <6384> : streams <1778474> : uri <2589710> Archived-At: Subject: Re: [tram] Review of TURNbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 11:53:51 -0000 SGkgTWFyYywNCg0KUGxlYXNlIHNlZSBpbmxpbmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTWFyYyBQZXRpdC0gDQo+IEh1Z3VlbmluDQo+IFNlbnQ6IFN1bmRheSwgT2N0b2JlciAy MiwgMjAxNyAxMDoxNiBQTQ0KPiBUbzogdHJhbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbdHJhbV0g UmV2aWV3IG9mIFRVUk5iaXMtMTENCj4gDQo+IFRoaXMgaXMgdGhlIHNlY29uZCBwYXJ0IG9mIG15 IHJldmlldyBvZiBUVVJOYmlzLTExLCBpLmUuIGV2ZXJ5dGhpbmcgDQo+IGJ1dCB0aGUgZHVhbCBh bGxvY2F0aW9uIHBhcnQuDQo+IA0KPiAtIFNlY3Rpb24gMi4xLCBsYXN0IHBhcmFncmFwaDoNCj4g DQo+IE1heSBiZSBhIHJlZmVyZW5jZSB0byBSRkMgNTc2NCBhbmQgUkZDIDc5ODMgY2FuIGJlIHVz ZWZ1bCBoZXJlLiAgU2FtZSANCj4gaW4gc2VjdGlvbiA0LCBzZWNvbmQgcGFyYWdyYXBoIGFuZCBm b2xsb3dpbmcuICBTYW1lIGF0IHRoZSBiZWdpbm5pbmcgDQo+IG9mIHNlY3Rpb24gMTEuICBBZ2Fp biBpbiBzZWN0aW9uIDExLjYgKGlmIG11bHRpcGxleGVkLCB0aGUgbWVzc2FnZSBpbiANCj4gdGhl IHJlc2VydmVkIHJhbmdlIGlzIG5vdCBuZWNlc3NhcmlseSBkaXNjYXJkZWQpLg0KDQpFdmVuIGlm IHRoZSBzYW1lIGhvc3QgdHJhbnNwb3J0IGFkZHJlc3MgaXMgdXNlZCBmb3Igb3RoZXIgcHJvdG9j b2xzLCBpbmNvbWluZyBwYWNrZXRzIHRvIHRoZSBUVVJOIGNoYW5uZWwgY2FuIGJlIGlkZW50aWZp ZWQgYnkganVzdCBleGFtaW5pbmcgdGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBwYWNrZXQuIA0K TWF5IGJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmcsIEkgZGlkIG5vdCBnZXQgYSBwcm9ibGVtID8N Cg0KPiANCj4gLSBTZWN0aW9uIDIuMiwgZmlyc3QgcGFyYWdyYXBoOg0KPiANCj4gSSB0aGluayB0 aGF0IGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgNzYzNSBtYXkgYmUgdXNlZnVsIHRo ZXJlLCANCj4gYXMgYWx0ZXJuYXRpdmUgdG8gdGhlIFNUVU4gYXV0aGVudGljYXRpb24gbWVjaGFu aXNtLg0KDQpZZXMsIHVwZGF0ZWQuIA0KDQo+IA0KPiAtIFNlY3Rpb24gMi45Og0KPiANCj4gVGhl IHdob2xlIDIuOSBzZWN0aW9uIGFuZCBzdWJzZWN0aW9ucyBsb29rcyBub3JtYXRpdmUgYW5kIHNv IHNob3VsZCBiZSANCj4gbW92ZWQgYWZ0ZXIgc2VjdGlvbiAzLCBwZXJoYXBzIG9uIHRoZWlyIG93 biB0b3AgbGV2ZWwgc2VjdGlvbi4NCg0KRG9uZS4gDQoNCj4gDQo+IC0gU2VjdGlvbiA0LCA0dGgg cGFyYWdyYXBoOg0KPiANCj4gSSB3b3VsZCByZXBsYWNlICJGb3IgZWFjaCBhbGxvY2F0aW9uLi4u IiBieSAiRm9yIGVhY2ggQWxsb2NhdGUgDQo+IHJlcXVlc3QuLi4iLCBiZWNhdXNlIG9mIHRoZSBk dWFsIGFsbG9jYXRpb24gZmVhdHVyZS4NCg0KRml4ZWQuIA0KDQo+IA0KPiAtIFNlY3Rpb24gNCwg MTJ0aCBwYXJhZ3JhcGg6DQo+IA0KPiBTaG91bGQgbWFrZSBjbGVhciBjbGVhciB0aGF0IFVEUCBj b3ZlcnMgYWxzbyBEVExTLg0KDQpZZXMsIHVwZGF0ZWQuDQoNCj4gDQo+IC0gU2VjdGlvbiA2LjEs IDJuZCBwYXJhZ3JhcGg6DQo+IA0KPiBJZiB0aGUgcG9ydCBpcyBtdWx0aXBsZXhlZCB3aXRoIG90 aGVyIHByb3RvY29scyAoUlRQLCBXZWJSdGMsIGV0Yy4uKSANCj4gdGhlbiBpdCBoYXMgdG8gcmV1 c2UgYW4gZXhpc3Rpbmcgc29ja2V0LiAgVGhlIGRvY3VtZW50IHNob3VsZCBleHBsYWluIHRoaXMu DQoNCkl0J3MgYWxyZWFkeSBjb3ZlcmVkIGluIFNlY3Rpb24gMi4xIChsYXN0IHBhcmFncmFwaCku IA0KDQo+IA0KPiAtIFNlY3Rpb24gNi4yLCAzdGggcGFyYWdyYXBoOg0KPiANCj4gSXMgaXQgdGlt ZSB0byByZWNvbW1lbmQgRFRMUyBpbnN0ZWFkIG9mIFVEUD8gIEluIHRoYXQgY2FzZSB3ZSBuZWVk IHRvIA0KPiBtYWtlIERUTFMgbWFuZGF0b3J5IGluIHNlY3Rpb24gNCBwYXJhZ3JhcGggMTEgKGFu ZCBJIHN1cHBvcnQgdGhhdCBjaGFuZ2UpLg0KDQpObywgRFRMUyBoYXMgYm90aCBhZHZhbnRhZ2Vz IChlLmcuIGRpY3Rpb25hcnkgYXR0YWNrKSAgYW5kIGRpc2FkdmFudGFnZXMgKGUuZy4gZG91Ymxl IGVuY3J5cHRpb24gb2YgYXBwbGljYXRpb24gZGF0YSkuIA0KDQo+IA0KPiAtIFNlY3Rpb24gNi40 LCBzZWNvbmQgYnVsbGV0Og0KPiANCj4gUmVwbGFjZSAiLi4uU1JWIHByb2NlZHVyZXMpLiIgd2l0 aCAiLi4uRE5TIHJlc29sdXRpb24gcHJvY2VkdXJlcykuIg0KDQpBbnkgc3BlY2lmaWMgcmVhc29u IGZvciB0aGUgcmVwbGFjZW1lbnQgPw0KDQo+IA0KPiAtIFNlY3Rpb25zIDE0LCAxNSBhbmQgMTY6 DQo+IA0KPiBUaGVzZSBhcmUgbm8gbG9uZ2VyIG5ldyBtZXRob2RzIGFuZCBhdHRyaWJ1dGVzLiAg U2VlIGFsc28gdGhlIG5leHQgDQo+IGNvbW1lbnQuDQoNCkZpeGVkLiANCg0KPiANCj4gLSBTZWN0 aW9uIDE5Og0KPiANCj4gSGVyZSB5b3UgbmVlZCB0byB1cGRhdGUgdGhlIGV4aXN0aW5nIG1ldGhv ZHMsIGF0dHJpYnV0ZXMgYW5kIGVycm9yIA0KPiBjb2RlIHNvIHRoZSBJQU5BIHJlZ2lzdHJpZXMg cG9pbnQgdG8gdGhlIFJGQy10by1iZSwgdGhlbiB5b3UgcmVxdWVzdCANCj4gYWxsb2NhdGlvbiBm b3IgdGhlIG5ldyBhdHRyaWJ1dGVzLiAgU2VlIHNlY3Rpb24gMTcgb2YgU1RVTmJpcyBvbiBhIHdh eSANCj4gdG8gZG8gdGhhdCAodGhhdCB3YXMgZG9uZSBmb2xsb3dpbmcgYSBkaXNjdXNzaW9uIHdp dGggdGhlIElBTkEgcmVwcmVzZW50YXRpdmUgYXQgYW4gSUVURiBtZWV0aW5nKS4NCg0KVGhhbmtz LCB1cGRhdGVkIGRyYWZ0LiANCg0KPiANCj4gTm90ZSB0aGF0IElDTVAgc2hvdWxkIGJlIGNvbXBy ZWhlbnNpb24tbWFuZGF0b3J5LCBub3Qgb3B0aW9uYWwsIGFzIHdlIA0KPiBkbyBub3Qgd2FudCBh biBvbGQgY2xpZW50IHRvIHJlamVjdCBhIERhdGEgaW5kaWNhdGlvbiB3aXRoIGFuIElDTVAgYXR0 cmlidXRlLg0KDQpJZiB0aGUgaW5kaWNhdGlvbiBjb250YWlucyB1bmtub3duIGNvbXByZWhlbnNp b24tcmVxdWlyZWQgYXR0cmlidXRlcywgdGhlIGJlaGF2aW9yIGlzIHRoZSBpbmRpY2F0aW9uIGlz IGRpc2NhcmRlZCBhbmQgcHJvY2Vzc2luZyBjZWFzZXMuDQoNCj4gDQo+IEFsc28sIEkgZG8gbm90 IGtub3cgd2hhdCB0aGlzIFNlbmRFcnIgbWV0aG9kIGlzLg0KDQpSZW1vdmVkIFNlbmRFcnIgKHN0 YWxlIGVudHJ5IGZyb20gYSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCkuDQoNCj4gDQo+ IA0KPiBOaXRzDQo+IC0tLS0NCj4gDQo+IFNlY3Rpb24gMToNCj4gDQo+IHMvY29ubmVjdGlvbiB0 byB0aGUgSW50ZXJuZXQgLi9jb25uZWN0aW9uIHRvIHRoZSBJbnRlcm5ldC4vDQo+IA0KPiBTZWN0 aW9uIDIuNCwgZmlyc3QgcGFyYWdyYXBoOg0KPiANCj4gVGhlIHRleHQgc3dpdGNoZXMgYmV0d2Vl biB0aGUgd29yZHMgIm1lY2hhbmlzbXMiIGFuZCAid2F5Ii4gIENob29zZSANCj4gb25lLg0KPiAN Cj4gU2VjdGlvbiA2LjIsIGl0ZW0gODoNCj4gDQo+IHMvQURESVRJT05BTC0gQUREUkVTUy1GQU1J TFkvQURESVRJT05BTC1BRERSRVNTLUZBTUlMWS8NCj4gDQo+IFNlY3Rpb24gMTIuMSwgIlByZWZl cnJlZCBCZWhhdmlvciINCj4gDQo+IHMvTGFiZWwgRmllbGRbUkZDMzY5N10vTGFiZWwgRmllbGQg W1JGQzM2OTddLw0KPiANCj4gU2VjdGlvbiAyMToNCj4gDQo+IHMvQUREUkVTUy1FUlJSLUNPREUv QUREUkVTUy1FUlItQ09ERS8NCj4gDQo+IFNlY3Rpb24gMjI6DQo+IA0KPiBzL29yZ2luYWwvb3Jp Z2luYWwvDQoNClRoYW5rcywgZml4ZWQgYWxsIGFib3ZlIG5pdHMuDQoNCkNoZWVycywNCi1UaXJ1 DQoNCj4gDQo+IC0tDQo+IE1hcmMgUGV0aXQtSHVndWVuaW4NCj4gRW1haWw6IG1hcmNAcGV0aXQt aHVndWVuaW4ub3JnDQo+IEJsb2c6IGh0dHBzOi8vbWFyYy5wZXRpdC1odWd1ZW5pbi5vcmcNCj4g UHJvZmlsZTogaHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL3BldGl0aHVnDQoNCg== From nobody Fri Feb 9 04:51:40 2018 Return-Path: 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 4C2A012778D for ; Fri, 9 Feb 2018 04:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 3k2hwTviV2Ll for ; Fri, 9 Feb 2018 04:51:34 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C0B120727 for ; Fri, 9 Feb 2018 04:51:34 -0800 (PST) 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=1518180693; h=From: To: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-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=D R6Xmzx7R2wpEjJz4uFtbV05XnrKKLi+mVoZgKSAOY 4=; b=Lgjs4+vV6SnwLENEFOOZjtghgpuM8xKw/4GwRpa5dmg7 eCbbdyb1icsWvgtNtWSd2QNRa6OCkGnu0vsHF6VOWRGNceV/zK vyTjXhWXoq3y4FofIIoBh8T3BvLcDX5CIxU+tP1LvTLQ9yWFhc GjeKD7JdYntAadbWiABrS5e9ilM= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 63fe_9a28_af04bd77_f510_43bd_a34e_ae033fce9012; Fri, 09 Feb 2018 06:51:32 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 05:51:11 -0700 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 05:51:10 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 9 Feb 2018 05:51:10 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 05:51:08 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1468.namprd16.prod.outlook.com (10.173.211.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 9 Feb 2018 12:51:08 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0464.017; Fri, 9 Feb 2018 12:51:08 +0000 From: "Konda, Tirumaleswar Reddy" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] Review of dual allocation in TURNbis-11 Thread-Index: AQHTRFmkTUXySTsG3EGzRBQMWeAaDaLmPU1QgAnZ7oCArKMPEA== Date: Fri, 9 Feb 2018 12:51:08 +0000 Message-ID: References: <65c75449-152c-1ce7-7c81-460ca589d9f0@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1468; 7:K2MKLjt5NkAm9XzquXZUyN8TBVk7gIZsv5f112qgZusmS0z990r6ZKxGaGb951deRk0nAQbcgEuCy6Mz/YSoDX/BVGX+yFL9DvdijiTd1g1KIYCWQx+4IYraa87ttfpEZ923eiOTYKROS2MBu09v4kq443Xpy2pzSz3W3ezfcs3ohdHrsSSawMvXJ0wCb0xOhnW8yMcxYwHRBfE/vUCEbY5hUyXkdMN6wqxIKSZ5EDDa+YsQZUeI/Q36YR3QpbiZ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6d8e69d1-97ed-40ce-53eb-08d56fbbca77 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1468; x-ms-traffictypediagnostic: DM5PR16MB1468: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(128460861657000)(213716511872227)(81160342030619)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(3002001)(93006095)(93001095)(10201501046)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1468; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1468; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(396003)(39380400002)(39850400004)(32952001)(13464003)(51444003)(252514010)(189003)(199004)(52314003)(478600001)(74316002)(5660300001)(45080400002)(72206003)(7736002)(305945005)(66066001)(186003)(55016002)(26005)(77096007)(6306002)(9686003)(68736007)(102836004)(53936002)(33656002)(316002)(3280700002)(25786009)(76176011)(2950100002)(59450400001)(6506007)(6436002)(229853002)(53546011)(3846002)(6116002)(105586002)(2501003)(81156014)(81166006)(8936002)(97736004)(80792005)(2900100001)(2906002)(966005)(14454004)(8676002)(106356001)(7696005)(3660700001)(6246003)(86362001)(99286004)(110136005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1468; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Kv8h9SHyExqLjARgfxYe3XDGv5935ZXGqEp7AvmUCYYCSotFCJUxL7RKiF2TmOXQP/kG//GToSp9tyygUl4Dmw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6d8e69d1-97ed-40ce-53eb-08d56fbbca77 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 12:51:08.8397 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1468 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6219> : inlines <6384> : streams <1778478> : uri <2589734> Archived-At: Subject: Re: [tram] Review of dual allocation in TURNbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 12:51:37 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJjIFBldGl0LUh1Z3Vlbmlu IFttYWlsdG86cGV0aXRodWdAYWNtLm9yZ10NCj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDIyLCAy MDE3IDk6MzggUE0NCj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPFRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbdHJhbV0gUmV2aWV3IG9mIGR1YWwgYWxsb2NhdGlvbiBpbiBUVVJOYmlzLTExDQo+IA0KPiBJ bmxpbmUuDQo+IA0KPiBPbiAxMC8xNi8yMDE3IDA3OjE0IFBNLCBLb25kYSwgVGlydW1hbGVzd2Fy IFJlZGR5IHdyb3RlOg0KPiA+IFRoYW5rcyBNYXJjIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3LCBQ bGVhc2Ugc2VlIGlubGluZQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNYXJjIFBldGl0LQ0KPiA+PiBIdWd1ZW5pbg0KPiA+PiBTZW50OiBTYXR1cmRheSwgT2N0b2Jl ciAxNCwgMjAxNyAxMjo1OSBBTQ0KPiA+PiBUbzogdHJhbUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0 OiBbdHJhbV0gUmV2aWV3IG9mIGR1YWwgYWxsb2NhdGlvbiBpbiBUVVJOYmlzLTExDQo+ID4+DQo+ ID4+IEkgc2hvdWxkIGZpcnN0IGFwb2xvZ2l6ZSB0aGUgdGhlIGRlbGF5IGluIHJldmlld2luZyB0 aGlzIGRyYWZ0LiAgSQ0KPiA+PiBuZXZlciBtYW5hZ2VkIHRvIGdldCBhIHNwb25zb3JzaGlwIHRo YXQgc3BhbnMgdGhlIHdob2xlIGxpZmV0aW1lIG9mIGENCj4gPj4gZHJhZnQgKG9yIGEgV29ya2lu ZyBHcm91cCBmb3IgdGhhdCBtYXR0ZXIpLCBhbmQgdGhhdCB3aHkgaXQgaXMgc28NCj4gPj4gZGlm ZmljdWx0IGZvciBtZSB0byB3b3JrIG9uIElFVEYgc3R1ZmYgaW4gYSBzdXN0YWluZWQgYW5kIGNv bnNpc3RlbnQgbWFubmVyLg0KPiA+Pg0KPiA+PiBBbnl3YXksIEkgd2FzIHdvcmtpbmcgb24gYSBy ZXZpZXcgZm9yIHR1cm5iaXMtMTEgdGhhdCB3YXMNCj4gPj4gc3BlY2lmaWNhbGx5IGZvY3VzaW5n IG9uIHRoZSBzeW5jaHJvbml6YXRpb24gd2l0aCBzdHVuYmlzLCBidXQgSSBrZXB0DQo+ID4+IGJl IGRpc3RyYWN0ZWQgYnkgaXNzdWVzIHJlbGF0ZWQgdG8gdGhlIGR1YWwgYWxsb2NhdGlvbiBmZWF0 dXJlLiAgU28gSQ0KPiA+PiBkZWNpZGVkIGluc3RlYWQgdG8gc2VuZCBhIHNlcGFyYXRlIGVtYWls IGZvciB0aGF0LCB0byBtYWtlIHRoaW5ncyBsZXNzDQo+IGNvbmZ1c2luZy4NCj4gPj4NCj4gPj4g TXkgbWFpbiBjb21tZW50IGFib3V0IHRoZSBkdWFsIGFsbG9jYXRpb24gYXBwcm9hY2ggaXMgYWJv dXQgdGhlDQo+ID4+IGNob2ljZSBvZiBhZGRpbmcgYSBuZXcgYXR0cmlidXRlIGZvciB0aGF0LiAg U1RVTiBzdXBwb3J0cyBzZW5kaW5nDQo+ID4+IG11bHRpcGxlIGF0dHJpYnV0ZXMgb2YgdGhlIHNh bWUgdHlwZSwgYW5kIGhhcyBhIGRlZmF1bHQgcHJvY2Vzc2luZw0KPiA+PiBydWxlIGZvciB0aGVt ICgiQW55IGF0dHJpYnV0ZSB0eXBlIE1BWSBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgaW4gYQ0KPiA+ PiBTVFVOIG1lc3NhZ2UuICBVbmxlc3Mgc3BlY2lmaWVkIG90aGVyd2lzZSwgdGhlIG9yZGVyIG9m IGFwcGVhcmFuY2UgaXMNCj4gPj4gc2lnbmlmaWNhbnQ6ICBvbmx5IHRoZSBmaXJzdCBvY2N1cnJl bmNlIG5lZWRzIHRvIGJlIHByb2Nlc3NlZCBieSBhDQo+ID4+IHJlY2VpdmVyLCBhbmQgYW55IGR1 cGxpY2F0ZXMgTUFZIGJlIGlnbm9yZWQgYnkgYQ0KPiA+PiByZWNlaXZlci4iKQ0KPiA+Pg0KPiA+ PiBTbyBhIFRVUk5iaXMgY2xpZW50IHRoYXQgd2FudHMgdG8gZG8gYSBkdWFsIGFsbG9jYXRpbmcg YWRkcyB0d28NCj4gPj4gUkVRVUVTVEVELSBBRERSRVNTLUZBTUlMWSAoUkFGKSwgb25lIGZvciBJ UHY0IGFuZCBvbmUgZm9yIElQdjYuICBBbg0KPiA+PiBSRkMgNTc2NiBzZXJ2ZXIgd2lsbCBqdXN0 IHVzZSB0aGUgZmlyc3Qgb25lIGFuZCBpZ25vcmUgdGhlIHNlY29uZC4NCj4gPj4gVGhlIFRVUk5i aXMgY2xpZW50IHJlY2VpdmVzIG9ubHkgb25lIFhPUi1SRUxBWUVELUFERFJFU1MgKFhSQSksIGZv cg0KPiB0aGUgZmlyc3QgUkFGIGl0IHNlbnQuDQo+ID4+DQo+ID4+IFRoZSBjbGllbnQgY2FuIGNo b29zZSB0aGUgb3JkZXIsIHNvIGl0IHJlY2VpdmVzIGltbWVkaWF0ZWx5IGEgWFJBDQo+ID4+IGZy b20gdGhlIGZhbWlseSBpdCBpcyBtb3N0IGludGVyZXN0ZWQgaW4sIGFuZCBjYW4gdHJ5IGEgc2Vj b25kDQo+ID4+IGFsbG9jYXRpb24gZm9yIHRoZSBvdGhlciBpZiB0aGUgc2VydmVyIGlzIGltcGxl bWVudGluZyBSRkMgNTc2Ng0KPiA+DQo+ID4NCj4gPiBObywgdGhlIGFib3ZlIGNoYW5nZSBjb250 cmFkaWN0cyB0aGUgYmVoYXZpb3IgZGVmaW5lZCBpbg0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2MTU2I3NlY3Rpb24tMw0KPiA+IDxzbmlwPg0KPiA+DQo+ID4gICAgVFVSTiBz ZXJ2ZXJzIGFsbG9jYXRlIGEgc2luZ2xlIHJlbGF5ZWQgdHJhbnNwb3J0IGFkZHJlc3MgcGVyDQo+ ID4gICAgYWxsb2NhdGlvbiByZXF1ZXN0LiAgVGhlcmVmb3JlLCBBbGxvY2F0ZSByZXF1ZXN0cyBj YW5ub3QgY2FycnkgbW9yZQ0KPiA+ICAgIHRoYW4gb25lIFJFUVVFU1RFRC1BRERSRVNTLUZBTUlM WSBhdHRyaWJ1dGUuICBDb25zZXF1ZW50bHksIGEgY2xpZW50DQo+ID4gICAgdGhhdCB3aXNoZXMg dG8gYWxsb2NhdGUgbW9yZSB0aGFuIG9uZSByZWxheWVkIHRyYW5zcG9ydCBhZGRyZXNzIGF0IGEN Cj4gPiAgICBUVVJOIHNlcnZlciAoZS5nLiwgYW4gSVB2NCBhbmQgYW4gSVB2NiBhZGRyZXNzKSBu ZWVkcyB0byBwZXJmb3JtDQo+ID4gICAgc2V2ZXJhbCBhbGxvY2F0aW9uIHJlcXVlc3RzIChvbmUg YWxsb2NhdGlvbiByZXF1ZXN0IHBlciByZWxheWVkDQo+ID4gICAgdHJhbnNwb3J0IGFkZHJlc3Mp Lg0KPiA+IDwvc25pcD4NCj4gPg0KPiA+IFlvdSBtYXkgd2FudCB0byBnbyB0aHJvdWdoIHRoZSBs b25nIGRpc2N1c3Npb24gaW4gdGhlIFdHIHRvIHBpY2sgYSBuZXcNCj4gPiBhdHRyaWJ1dGUgKEFE RElUSU9OQUwtQUREUkVTUy1GQU1JTFkpIGZvciBkdWFsLXN0YWNrIGFsbG9jYXRpb24uDQo+IA0K PiBJIHN0aWxsIHRoaW5rIGl0IGlzIHVubmVjZXNzYXJpbHkgY29tcGxpY2F0ZWQsIGJ1dCBhbGwg cmlnaHQuDQo+IA0KPiA+DQo+ID4+DQo+ID4+IEkgdGhpbmsgdGhhdCB0aGlzIG1ha2VzIGZvciBz aW1wbGVyIHJ1bGVzIHRvIGltcGxlbWVudCBhbmQgc2ltcGxlciB0ZXh0Lg0KPiA+Pg0KPiA+PiBO b3cgc29tZSBtb3JlIHNwZWNpZmljIGNvbW1lbnRzIGFib3V0IHRoZSB0ZXh0Og0KPiA+Pg0KPiA+ PiAtIFRpdGxlIGFuZCBhYnN0cmFjdA0KPiA+Pg0KPiA+PiBUaGUgZHJhZnQgc2hvdWxkIG9ic29s ZXRlIGJvdGggUkZDIDU3NjYgYW5kIFJGQyA2MTU2LCBhbmQgdGhhdCBmYWN0DQo+ID4+IHNob3Vs ZCBiZSByZXBlYXRlZCBpbiB0aGUgYWJzdHJhY3QuICBUaGUgYXV0aG9ycyBvZiBSRkMgNjE1NiBz aG91bGQNCj4gPj4gYmUgYWNrbm93bGVkZ2VkIGVpdGhlciBpbiB0aGUgQWNrbm93bGVkZ21lbnQg b3IgQ29udHJpYnV0b3JzIHNlY3Rpb24uDQo+ID4NCj4gPiBEb25lLg0KPiA+DQo+ID4+DQo+ID4+ IC0gU2VjdGlvbiA1Lg0KPiA+Pg0KPiA+PiBUaGUgZmlyc3QgaXRlbSBpbiB0aGUgYnVsbGV0IGxp c3Qgc2hvdWxkIHNheSAidGhlIHJlbGF5ZWQgdHJhbnNwb3J0DQo+ID4+IGFkZHJlc3Mgb3IgYWRk cmVzc2VzOyINCj4gPg0KPiA+IFVwZGF0ZWQgbGluZSB0byBzYXkgIkFsbCBUVVJOIG9wZXJhdGlv bnMgcmV2b2x2ZSBhcm91bmQgYWxsb2NhdGlvbnMsIGFuZCBhbGwNCj4gVFVSTiBtZXNzYWdlcyBh cmUgYXNzb2NpYXRlZCB3aXRoIGVpdGhlciBhIHNpbmdsZSBvciBkdWFsIGFsbG9jYXRpb24uIg0K PiA+DQo+ID4+DQo+ID4+IEluIHRoZSB0aGUgZm91cnRoIGl0ZW0sIHRoZXJlIGlzIG9uZSB0aW1l LXRvLWV4cGlyeSBwZXIgcmVsYXllZA0KPiA+PiB0cmFuc3BvcnQgYWRkcmVzcy4NCj4gPj4NCj4g Pj4gU2FtZSBmb3IgdGhlIGxpc3Qgb2YgcGVybWlzc2lvbnMgaW4gdGhlIGZpZnRoIGl0ZW0uDQo+ ID4+DQo+ID4+ICJCb3RoIHRoZSByZWxheWVkIHRyYW5zcG9ydCBhZGRyZXNzIGFuZCB0aGUgNS10 dXBsZSBNVVNUIGJlIHVuaXF1ZQ0KPiA+PiBhY3Jvc3MgYWxsIGFsbG9jYXRpb25zLCBzbyBlaXRo ZXIgb25lIGNhbiBiZSB1c2VkIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZQ0KPiBhbGxvY2F0aW9u LiINCj4gPj4NCj4gPj4gV2l0aCB0aGUgZHVhbCBhbGxvY2F0aW9uLCB0aGUgNS10dXBsZSBubyBs b25nZXIgdW5pcXVlbHkgaWRlbnRpZnkgYW4NCj4gYWxsb2NhdGlvbi4NCj4gPg0KPiA+IFllcywg Zml4ZWQuDQo+ID4NCj4gPj4NCj4gPj4gLSBTZWN0aW9uIDYuMg0KPiA+Pg0KPiA+PiBJIHdvdWxk IHN1Z2dlc3QgdG8gbWFrZSBBRERSRVNTLUVSUk9SLUNPREUgbW9yZSBnZW5lcmljIGJ5DQo+IHJl bmFtaW5nDQo+ID4+IGl0IGFzIFdBUk5JTkctQ09ERSBhbmQgdXNlIHRoZSBzYW1lIGZvcm1hdCB0 aGFuIGZvciBFUlJPUi1DT0RFLg0KPiBUaGVuDQo+ID4+IGFsbG9jYXRlIGEgbmV3IGVycm9yIGNv ZGUgZm9yIHRoYXQgc3BlY2lmaWMgd2FybmluZy4gIEkgd291bGQgc3VnZ2VzdA0KPiA+PiB0byBy ZXF1ZXN0IHRoZSAweDgwMDkgY29kZXBvaW50IGZvciB0aGF0IGF0dHJpYnV0ZS4NCj4gPg0KPiA+ IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgbmVlZCB0byBjaGFuZ2UgQUREUkVTUy1FUlJPUi1DT0RF ICENCj4gDQo+IFRvIG1ha2UgaXQgbW9yZSBnZW5lcmljIGFuZCByZXVzYWJsZSBpbiBmdXR1cmUg c3BlY2lmaWNhdGlvbnMuDQoNCkFERFJFU1MtRVJST1ItQ09ERSBjYW5ub3QgdXNlIHRoZSBzYW1l IGZvcm1hdCBhcyBFUlJPUi1DT0RFLCBBRERSRVNTLUVSUk9SLUNPREUgc2lnbmFscyB0aGUgSVAg YWRkcmVzcyBmYW1pbHkgZm9yIHdoaWNoIHRoZSB3YXJuaW5nIGlzIGdlbmVyYXRlZCArIGFsbCB0 aGUgZmllbGRzIGluIHRoZSBFUlJPUi1DT0RFLiANCg0KPiANCj4gPg0KPiA+Pg0KPiA+PiBBbHNv IEkgdGhpbmsgd2UgbmVlZHMgdHdvIGRpZmZlcmVudCB3YXJuaW5ncywgb25lIHRoYXQgc3RhdGVz IHRoYXQNCj4gPj4gZHVhbCBhbGxvY2F0aW9uIGlzIG5vdCBhdmFpbGFibGUgaW4gYSBUVVJOYmlz IHNlcnZlciwgYnV0IGJvdGgNCj4gPj4gcHJvdG9jb2xzIGFyZSBhdmFpbGFibGUsIGFuZCBhbm90 aGVyIHRoYXQgc2F5cyB0aGF0IGR1YWwgYWxsb2NhdGlvbg0KPiA+PiBmYWlsZWQgYmVjYXVzZSBv bmUgb2YgdGhlIHR3byBwcm90b2NvbHMgaXMgbm90IGF2YWlsYWJsZS4gIFRoaXMgaXMgdG8NCj4g Pj4gbGV0IHRoZSBjbGllbnQga25vdyB0aGF0IGl0IGlzIHVzZWxlc3MgdG8gdHJ5IGFub3RoZXIg YWxsb2NhdGlvbiBmb3IgdGhlDQo+IG1pc3NpbmcgcHJvdG9jb2wuDQo+ID4NCj4gPiBJIGRvbid0 IGdldCB0aGUgcmVhc29uIGZvciB0d28gZGlmZmVyZW50IHdhcm5pbmdzLg0KPiANCj4gQSBzZXJ2 ZXIgbWF5IHN1cHBvcnQgYm90aCBJUHY2IGFuZCBJUHY0IGFsbG9jYXRpb25zIGFuZCBub3Qgc3Vw cG9ydCBkdWFsDQo+IGFsbG9jYXRpb24sIGluIHdoaWNoIGNhc2UgdGhlIGNsaWVudCBjYW4gZG8g YSBzZWNvbmQgYWxsb2NhdGlvbiBmb3IgdGhlIElQdjYNCj4gcmVsYXllZCBhZGRyZXNzLg0KDQpJ ZiB0aGUgc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgZHVhbCBhbGxvY2F0aW9uIGJ1dCBzdXBwb3J0 cyBib3RoIElQdjYgYW5kIElQdjQgYWxsb2NhdGlvbnMsIGl0IHdpbGwgb25seSBhbGxvY2F0ZSB0 aGUgSVB2NCByZWxheWVkIGFkZHJlc3MgYW5kIG5vdCB3aWxsIG5vdCByZXR1cm4gQUREUkVTUy1F UlJPUi1DT0RFIGluIHRoZSByZXNwb25zZSwgdGhlIGNsaWVudCB3aWxsIGtub3cgdGhlIHNlcnZl ciBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZIGF0dHJp YnV0ZSAoQURESVRJT05BTC1BRERSRVNTLUZBTUlMWSBpcyBhIGNvbXByZWhlbnNpb24tb3B0aW9u YWwgYXR0cmlidXRlKS4gDQoNCj4gDQo+IEFsdGVybmF0aXZlbHkgdGhlIHNlcnZlciBtYXkgbm90 IHN1cHBvcnQgSVB2NiBhdCBhbGwsIGluIHdoaWNoIGNhc2UgdGhlIHNlY29uZA0KPiBhbGxvY2F0 aW9uIHdpbGwgZmFpbCBhbmQgd2FzIHVubmVjZXNzYXJ5Lg0KDQpBRERSRVNTLUVSUk9SLUNPREUg c2lnbmFscyBib3RoIHVuc3VwcG9ydGVkIElQIGFkZHJlc3MgdHlwZSAoMHgwMiAoSVB2NiBhZGRy ZXNzIGZhbWlseSkpIGFuZCB0aGUgcmVhc29uIGZvciBmYWlsdXJlICg0NDAgKHVuc3VwcG9ydGVk IGFkZHJlc3MgZmFtaWx5KSkuIA0KDQpDaGVlcnMsDQotVGlydQ0KDQo+IA0KPiBVc2luZyB0d28g ZGlmZmVyZW50IHdhcm5pbmdzIHBlcm1pdHMgdG8ga25vdyBpZiB0aGUgc2Vjb25kIGFsbG9jYXRp b24gd2lsbA0KPiBzdWNjZWVkIG9yIG5vdC4NCj4gDQo+ID4NCj4gPj4NCj4gPj4gV2hhdCBpcyB0 aGUgcG9saWN5IHdoZW4gcmVzZXJ2aW5nIHRoZSBuZXh0IHBvcnQgd2l0aCB0aGUgRVZFTi1QT1JU DQo+ID4+IGF0dHJpYnV0ZSBpbiBhIGR1YWwgYWxsb2NhdGlvbiwgYnV0IG9uZSBvZiB0aGVtIGZh aWxzIHRvIGZpbmQgYSBwYWlyDQo+ID4+IG9mIHN1YnNlcXVlbnQgcG9ydHMgYXZhaWxhYmxlPw0K PiA+DQo+ID4gSXQncyBkaXNjdXNzZWQgaW4gc2VjdGlvbiA2LjENCj4gPg0KPiA+IDxzbmlwPg0K PiA+ICAgIENsaWVudHMgTVVTVCBOT1QNCj4gPiAgICBpbmNsdWRlIEFERElUSU9OQUwtQUREUkVT Uy1GQU1JTFkgYXR0cmlidXRlIGluIGEgQWxsb2NhdGUgcmVxdWVzdA0KPiA+ICAgIHRoYXQgY29u dGFpbnMgYW4gRVZFTi1QT1JUIGF0dHJpYnV0ZSB3aXRoIHRoZSBSIGJpdCBzZXQgdG8gMS4NCj4g PiA8L3NuaXA+DQo+ID4NCj4gPj4NCj4gPj4gSXQgaXMgbm90IHNhaWQgdGhhdCB0aGUgQWxsb2Nh dGUgc3VjY2Vzc2Z1bCByZXNwb25zZSBtdXN0IGNvbnRhaW4gdHdvDQo+ID4+IFhSQXMgYWZ0ZXIg YSBzdWNjZXNzZnVsIGR1YWwgYWxsb2NhdGlvbi4NCj4gPg0KPiA+IEdvb2QgcG9pbnQsIFVwZGF0 ZWQgZHJhZnQuDQo+ID4NCj4gPj4NCj4gPj4gSSB3b3VsZCBhbHNvIHN1Z2dlc3QgdG8gYWRkIHNv bWUgdGV4dCB0aGF0IHNheXMgdGhhdCB3aGVuIGEgVFVSTmJpcw0KPiA+PiBzZXJ2ZXIgc2VuZHMg YW4gQWxsb2NhdGUgc3VjY2VzcyByZXNwb25zZSwgaXQgbXVzdCBhbHdheXMgc2VuZCB0aGUNCj4g Pj4gWFJBcyBpbiB0aGUgc2FtZSBvcmRlciB0aGFuIHRoZSBSQUZzIHdlcmUgc2VudC4gIFNvIGlu IGNhc2UgdGhlDQo+ID4+IHNlcnZlciBzZW5kcyBiYWNrIGJ5IG1pc3Rha2UgdHdvIFhSQXMsIHRo ZSBmaXJzdCBvbmUgbWF0Y2hlcyB0aGUgb25lDQo+IHJlcXVlc3RlZCBieSB0aGUgY2xpZW50Lg0K PiA+Pg0KPiA+PiBUaGUgYnVsbGV0IGxpc3QgYXQgdGhlIGVuZCBuZWVkcyBhbHNvIHRvIGJlIGZp eGVkIGZvciBkdWFsIGFsbG9jYXRpb24uDQo+ID4NCj4gPiBBZ3JlZWQsIGZpeGVkLg0KPiA+DQo+ ID4+DQo+ID4+IC0gU2VjdGlvbiA2LjMNCj4gPj4NCj4gPj4gSGVyZSdzIHRvbywgdGhlIHRleHQg bmVlZHMgdG8gYmUgdXBkYXRlZCBmb3IgdGhlIGR1YWwgYWxsb2NhdGlvbiBjYXNlLg0KPiA+DQo+ ID4NCj4gPiBZdXAsIHVwZGF0ZWQuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gLVRpcnUNCj4gPg0K PiANCj4gDQo+IC0tDQo+IE1hcmMgUGV0aXQtSHVndWVuaW4NCj4gRW1haWw6IG1hcmNAcGV0aXQt aHVndWVuaW4ub3JnDQo+IEJsb2c6IGh0dHBzOi8vbWFyYy5wZXRpdC1odWd1ZW5pbi5vcmcNCj4g UHJvZmlsZTogaHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL3BldGl0aHVnDQoNCg== From nobody Fri Feb 9 05:13:01 2018 Return-Path: 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 0E22112895E; Fri, 9 Feb 2018 05:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pqjplx7zcBt; Fri, 9 Feb 2018 05:12:58 -0800 (PST) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88E312778D; Fri, 9 Feb 2018 05:12:57 -0800 (PST) Received: from [IPv6:2601:648:8301:730f:2436:a9dd:2d25:3db0] (unknown [IPv6:2601:648:8301:730f:2436:a9dd:2d25:3db0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6940FAE814; Fri, 9 Feb 2018 14:12:54 +0100 (CET) To: Spencer Dawkins at IETF , Gonzalo Camarillo Cc: tram-chairs@ietf.org, tram@ietf.org, tasveren@rbbn.com References: From: Marc Petit-Huguenin Message-ID: <7ccc7632-7457-945e-d449-bbf5878f1708@acm.org> Date: Fri, 9 Feb 2018 05:12:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CQJeF6zR6Wq3PFRzQXoR4huirITiqmq2B" Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-stunbis-15 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 13:13:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CQJeF6zR6Wq3PFRzQXoR4huirITiqmq2B Content-Type: multipart/mixed; boundary="nkMAAhVo0FYihXvuYSMQOuix3wHdv0hgJ"; protected-headers="v1" From: Marc Petit-Huguenin To: Spencer Dawkins at IETF , Gonzalo Camarillo Cc: tram-chairs@ietf.org, tram@ietf.org, tasveren@rbbn.com Message-ID: <7ccc7632-7457-945e-d449-bbf5878f1708@acm.org> Subject: Re: [tram] AD Evaluation of draft-ietf-tram-stunbis-15 References: In-Reply-To: --nkMAAhVo0FYihXvuYSMQOuix3wHdv0hgJ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Spencer, I updated my copy of stunbis with the modifications below (and I already = had some modifications from another review that was sent directly to us).= I'll publish -16 on 2018-02-23, after the end of the last call. Please also see my comment below. Thanks. On 02/06/2018 11:42 AM, Spencer Dawkins at IETF wrote: > Dear All, >=20 > On Fri, Feb 2, 2018 at 7:23 AM, Gonzalo Camarillo < > gonzalo.camarillo@ericsson.com> wrote: >=20 >> Gonzalo Camarillo has requested publication of draft-ietf-tram-stunbis= -15 >> as Proposed Standard on behalf of the TRAM working group. >=20 >=20 > This looks good. I have a couple of nits, but I'll request Last Call no= w, > and you can consider them at an appropriate time. >=20 > Thanks! >=20 > Spencer >=20 > -- >=20 > Is there a reference for the SIP practice described here > The structure of the key when used with long-term credentials > facilitates deployment in systems that also utilize SIP. Typicall= y, > SIP systems utilizing SIP's digest authentication mechanism do not= > actually store the password in the database. Rather, they store a= > value called H(A1), which is equal to the key defined above. >=20 > that you could point to? I could not find any. Apparently RFC 3261 do not even use the term "H(A1= )". >=20 > In this text, >=20 > o Made clear that the RTO is considered stale if there is no > transactions with the server. >=20 > there's a numbering mismatch - I'm not sure if this should be >=20 > o Made clear that the RTO is considered stale if there are no > transactions with the server. >=20 > or something else. I do not get it. The replaced text you propose seems identical. >=20 > Unless you're intentionally using lower-case requirement keywords, and = it > doesn't look like you are, you may want to update your reference to RFC= > 2119, to https://tools.ietf.org/html/rfc8174. ADs have been mentioning = this > on their ballots. Done. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --nkMAAhVo0FYihXvuYSMQOuix3wHdv0hgJ-- --CQJeF6zR6Wq3PFRzQXoR4huirITiqmq2B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlp9nlMACgkQKcRFldZq fsQrNBAAinGnLr0QrApNzsDFJqHHh/0PmzCtS7ctkhB3N66ed0UA2rgUSbRo1bLg zymvZbPdNr6vTb4owJXPxQyI2CTfynsGhmJa74SeKjwL+dapAFPCQUxY54t99wY1 sYkDL+chxrD/LrzNVPYCAGVIk1/2/Qmft7nnCGcTP5qVOHHFEhYeWVEt5KeKc15o 0pAMH1kALUQEtt6mB+ahyP6f59mhNH3/xxiznMX+txpen7isBv78ZBLgktsaUaZl 4pOzkqumUpxKxUp5C8CKZhZYD19fY5L+LEBmGhNn+o7YUslghbdWwJ68SoqKjs7C ku7MIkqJEPRBAS86Wn3xXdDqwxRLXS36Y8TlVPgXAFOP5U/sI1GjiYkNUdDW1kBf yK+zFhQ8BkI3+iob2YzN97zdYTMW82dQmmJG+cwooM0eVW4hiVb8HSf0jWN2HgH9 py3jgtIJJfEnCWNx1Qn4Yj0bSmtsi97TFWiXblkAFOizzciPc7t2DQ+LlzWTypzP 8HNAfVHmznD4/eBUWCmNV5AN7vLbi5cKYht/uksUQAHLW3HeaAz1zAAk++3Bv+rR t2iE1XH8/GA1sTwIzucaTSqhSlrscRWCQw4X17ZVsGirp2saZ7HqKZlVvqqjS9Gy hUF4+7F5uVK69HOzIb8cjjT/Zm7wJKQUVoYOHNmYYZy3hSOvglE= =0se5 -----END PGP SIGNATURE----- --CQJeF6zR6Wq3PFRzQXoR4huirITiqmq2B-- From nobody Fri Feb 9 05:24:00 2018 Return-Path: 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 E9B1512946D for ; Fri, 9 Feb 2018 05:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmGw1dJ0vpyh for ; Fri, 9 Feb 2018 05:23:56 -0800 (PST) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0833124D6C for ; Fri, 9 Feb 2018 05:23:55 -0800 (PST) Received: from [IPv6:2601:648:8301:730f:2436:a9dd:2d25:3db0] (unknown [IPv6:2601:648:8301:730f:2436:a9dd:2d25:3db0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 0EC5BAE814; Fri, 9 Feb 2018 14:23:53 +0100 (CET) To: "Konda, Tirumaleswar Reddy" , "tram@ietf.org" References: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> From: Marc Petit-Huguenin Message-ID: Date: Fri, 9 Feb 2018 05:23:51 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7rEsAfn7azBgOuMWsLfMa2le5jap0fSJi" Archived-At: Subject: Re: [tram] Review of TURNbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 13:23:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7rEsAfn7azBgOuMWsLfMa2le5jap0fSJi Content-Type: multipart/mixed; boundary="qBJRlIHIbd4MCah2ceuMiKMYQNHuedmm6"; protected-headers="v1" From: Marc Petit-Huguenin To: "Konda, Tirumaleswar Reddy" , "tram@ietf.org" Message-ID: Subject: Re: [tram] Review of TURNbis-11 References: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> In-Reply-To: --qBJRlIHIbd4MCah2ceuMiKMYQNHuedmm6 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, My responses inline. On 02/09/2018 03:53 AM, Konda, Tirumaleswar Reddy wrote: > Hi Marc, >=20 > Please see inline >=20 >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit-=20 >> Huguenin >> Sent: Sunday, October 22, 2017 10:16 PM >> To: tram@ietf.org >> Subject: [tram] Review of TURNbis-11 >> >> This is the second part of my review of TURNbis-11, i.e. everything=20 >> but the dual allocation part. >> >> - Section 2.1, last paragraph: >> >> May be a reference to RFC 5764 and RFC 7983 can be useful here. Same = >> in section 4, second paragraph and following. Same at the beginning=20 >> of section 11. Again in section 11.6 (if multiplexed, the message in = >> the reserved range is not necessarily discarded). >=20 > Even if the same host transport address is used for other protocols, in= coming packets to the TURN channel can be identified by just examining th= e source address of the packet.=20 > May be I am missing something, I did not get a problem ? It was just an attempt to make TURN implementers aware of the demux issue= s. >=20 >> >> - Section 2.2, first paragraph: >> >> I think that an informative reference to RFC 7635 may be useful there,= =20 >> as alternative to the STUN authentication mechanism. >=20 > Yes, updated.=20 >=20 >> >> - Section 2.9: >> >> The whole 2.9 section and subsections looks normative and so should be= =20 >> moved after section 3, perhaps on their own top level section. >=20 > Done.=20 >=20 >> >> - Section 4, 4th paragraph: >> >> I would replace "For each allocation..." by "For each Allocate=20 >> request...", because of the dual allocation feature. >=20 > Fixed.=20 >=20 >> >> - Section 4, 12th paragraph: >> >> Should make clear clear that UDP covers also DTLS. >=20 > Yes, updated. >=20 >> >> - Section 6.1, 2nd paragraph: >> >> If the port is multiplexed with other protocols (RTP, WebRtc, etc..)=20 >> then it has to reuse an existing socket. The document should explain = this. >=20 > It's already covered in Section 2.1 (last paragraph).=20 >=20 >> >> - Section 6.2, 3th paragraph: >> >> Is it time to recommend DTLS instead of UDP? In that case we need to = >> make DTLS mandatory in section 4 paragraph 11 (and I support that chan= ge). >=20 > No, DTLS has both advantages (e.g. dictionary attack) and disadvantage= s (e.g. double encryption of application data).=20 OK. >=20 >> >> - Section 6.4, second bullet: >> >> Replace "...SRV procedures)." with "...DNS resolution procedures)." >=20 > Any specific reason for the replacement ? This is to not exclude NPATR procedures (RFC 5928). >=20 >> >> - Sections 14, 15 and 16: >> >> These are no longer new methods and attributes. See also the next=20 >> comment. >=20 > Fixed.=20 >=20 >> >> - Section 19: >> >> Here you need to update the existing methods, attributes and error=20 >> code so the IANA registries point to the RFC-to-be, then you request=20 >> allocation for the new attributes. See section 17 of STUNbis on a way= =20 >> to do that (that was done following a discussion with the IANA represe= ntative at an IETF meeting). >=20 > Thanks, updated draft.=20 >=20 >> >> Note that ICMP should be comprehension-mandatory, not optional, as we = >> do not want an old client to reject a Data indication with an ICMP att= ribute. >=20 > If the indication contains unknown comprehension-required attributes, t= he behavior is the indication is discarded and processing ceases. >=20 >> >> Also, I do not know what this SendErr method is. >=20 > Removed SendErr (stale entry from a previous version of the draft). >=20 >> >> >> Nits >> ---- >> >> Section 1: >> >> s/connection to the Internet ./connection to the Internet./ >> >> Section 2.4, first paragraph: >> >> The text switches between the words "mechanisms" and "way". Choose=20 >> one. >> >> Section 6.2, item 8: >> >> s/ADDITIONAL- ADDRESS-FAMILY/ADDITIONAL-ADDRESS-FAMILY/ >> >> Section 12.1, "Preferred Behavior" >> >> s/Label Field[RFC3697]/Label Field [RFC3697]/ >> >> Section 21: >> >> s/ADDRESS-ERRR-CODE/ADDRESS-ERR-CODE/ >> >> Section 22: >> >> s/orginal/original/ >=20 > Thanks, fixed all above nits. >=20 > Cheers, > -Tiru >=20 >> --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --qBJRlIHIbd4MCah2ceuMiKMYQNHuedmm6-- --7rEsAfn7azBgOuMWsLfMa2le5jap0fSJi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlp9oOcACgkQKcRFldZq fsSMvg/9HqB6FbzWxL1LL680ih7vtPYDimWLXlamC7tCrNmG0AzBLAEHX/Xl3p7R eTZIhUhzhLOFkHCs59BbfQlmtB7dZ0Gd0FFsQ8L0pGowMyyGLsWC5x6wqdbGm89C nF3b7Ygy1E6j2nxEdujKS1M5rrluys8SQzb1PVMmmnd6RsnqYZCIn1Yj7lt00OED ye0+rJINkh94IRzTHL3+AellPWqeCOfelOk7Wg5NqnJ9xkkkbjYZOAoWA8I/xzv6 Kcl+xUuNT9enW919acEHN+rIVe1DZafJifQGmGT/C2Mud0X2JUFQrRmcdTvjzo6D /JzbD+vKj4q9ZW0Zy/Rjgao0CmYl5kaIZMmHNOazfQBWl3YWoB+rTQaiTrfg+nxN pmTpBYi3Snl1lyfVLO5CQOEBq4xg1yv1NayRdy3bbh+ipTH3pdEaJsGU9BAneNbt bRUIZ45gd6m7VjTR3Id7Su4jgMxGsBml6pXvEatn1/McF0w9Qkx4rgPAoHf2T/9H +WEdcfuS9ObbekPHGtkEM9iainUZ6ZiZd+uUvg7efVwRz6saOKu5igIfyTv414Wo lpCz83FAMYAq+SYlBYzSlyV10COuyspv2VIIi0byAP/dihsHSXn5jtj9Wh/TMyKc pwl6i5pKbQY+4cptejtCVhwmxWy/rMvqtXzd7PEg6jWRRB6KLuY= =VdjW -----END PGP SIGNATURE----- --7rEsAfn7azBgOuMWsLfMa2le5jap0fSJi-- From nobody Fri Feb 9 05:45:56 2018 Return-Path: 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 74EA4129C53 for ; Fri, 9 Feb 2018 05:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 A4qEUlPbPe5R for ; Fri, 9 Feb 2018 05:45:51 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A3B126579 for ; Fri, 9 Feb 2018 05:45:50 -0800 (PST) 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=1518183945; h=From: To: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-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=V mlw7KBDnf8W5BczXqOlvrteFauGSQhV8uPemKXzcr c=; b=XHf0ylZejeqzqs92OY07ouBnqvIkwayEmnERvncTZuti f2vqzQGNByU34UU7KzHYquTfvHcdjtJ0k1Es2m0H8IVOElrrSz rX2cuvAsVyRP1uqqfxdQSLXEY7DzHfLWGI/fxjpgrn8W4jDV+d oNsZiCWuf9qR+AUYQc+bUgGBCE0= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 63fe_ac17_e0d8166c_2d1a_4fbb_a197_5da28f039d9b; Fri, 09 Feb 2018 07:45:45 -0600 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 06:45:41 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 9 Feb 2018 06:45:41 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 9 Feb 2018 06:45:39 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1497.namprd16.prod.outlook.com (10.173.211.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 9 Feb 2018 13:45:39 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0464.017; Fri, 9 Feb 2018 13:45:39 +0000 From: "Konda, Tirumaleswar Reddy" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] Review of TURNbis-11 Thread-Index: AQHTS1VEMV/cplA80E+CbiTeE9FOmaOcXoOggABdRYCAAAT7EA== Date: Fri, 9 Feb 2018 13:45:39 +0000 Message-ID: References: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1497; 7:bk17Kr6bH9Rj1w7TP8XkUnBy7TlhnCUk+aSk9iRqctQmxfkyeYiLNyK6+GQvlib3uiJWYW/XUMntDvV7NXU1B1OVybPxRXXYv1mogrJ0dhK+ffratDcdn1/MyoHjAERcRqu3FZUVWPWzlClk0gfxYcFOeTUuDM9uiAZT3Azkfq9TpW0a/Kx0BLcu/Pa8lbWOz63AdJtpIRiW2LQxFWhdynrBjeirDL4MQhaSFH8XMTScnt861mFwdWzSYwL0ZNPu x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a98d8ea1-ecc8-44f1-b918-08d56fc367c9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1497; x-ms-traffictypediagnostic: DM5PR16MB1497: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089)(128460861657000)(81160342030619)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(10201501046)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1497; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1497; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(39380400002)(396003)(366004)(13464003)(199004)(189003)(32952001)(252514010)(51444003)(55016002)(316002)(81156014)(66066001)(8936002)(6246003)(8676002)(53936002)(81166006)(5660300001)(2906002)(478600001)(106356001)(33656002)(3846002)(72206003)(6436002)(105586002)(9686003)(966005)(45080400002)(110136005)(7696005)(6116002)(6306002)(99286004)(68736007)(59450400001)(6506007)(97736004)(3280700002)(76176011)(2501003)(80792005)(229853002)(3660700001)(2950100002)(53546011)(86362001)(26005)(77096007)(25786009)(186003)(74316002)(2900100001)(102836004)(7736002)(305945005)(14454004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1497; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: agLZjNZqNnehwvn8Z2xbq/yhwxotONCYmtkzCxs7TPOg47blTiDaitmuQ72KFDATTkSGq1gBidBWM4YY4//uSQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a98d8ea1-ecc8-44f1-b918-08d56fc367c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 13:45:39.2278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1497 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6219> : inlines <6384> : streams <1778482> : uri <2589758> Archived-At: Subject: Re: [tram] Review of TURNbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 13:45:53 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyYyBQZXRpdC0NCj4gSHVndWVuaW4NCj4g U2VudDogRnJpZGF5LCBGZWJydWFyeSA5LCAyMDE4IDY6NTQgUE0NCj4gVG86IEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyB0 cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gUmV2aWV3IG9mIFRVUk5iaXMtMTEN Cj4gDQo+IEhpLA0KPiANCj4gTXkgcmVzcG9uc2VzIGlubGluZS4NCj4gDQo+IE9uIDAyLzA5LzIw MTggMDM6NTMgQU0sIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgd3JvdGU6DQo+ID4gSGkgTWFy YywNCj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1hcmMgUGV0aXQtDQo+ID4+IEh1Z3VlbmluDQo+ID4+IFNlbnQ6IFN1 bmRheSwgT2N0b2JlciAyMiwgMjAxNyAxMDoxNiBQTQ0KPiA+PiBUbzogdHJhbUBpZXRmLm9yZw0K PiA+PiBTdWJqZWN0OiBbdHJhbV0gUmV2aWV3IG9mIFRVUk5iaXMtMTENCj4gPj4NCj4gPj4gVGhp cyBpcyB0aGUgc2Vjb25kIHBhcnQgb2YgbXkgcmV2aWV3IG9mIFRVUk5iaXMtMTEsIGkuZS4gZXZl cnl0aGluZw0KPiA+PiBidXQgdGhlIGR1YWwgYWxsb2NhdGlvbiBwYXJ0Lg0KPiA+Pg0KPiA+PiAt IFNlY3Rpb24gMi4xLCBsYXN0IHBhcmFncmFwaDoNCj4gPj4NCj4gPj4gTWF5IGJlIGEgcmVmZXJl bmNlIHRvIFJGQyA1NzY0IGFuZCBSRkMgNzk4MyBjYW4gYmUgdXNlZnVsIGhlcmUuICBTYW1lDQo+ ID4+IGluIHNlY3Rpb24gNCwgc2Vjb25kIHBhcmFncmFwaCBhbmQgZm9sbG93aW5nLiAgU2FtZSBh dCB0aGUgYmVnaW5uaW5nDQo+ID4+IG9mIHNlY3Rpb24gMTEuICBBZ2FpbiBpbiBzZWN0aW9uIDEx LjYgKGlmIG11bHRpcGxleGVkLCB0aGUgbWVzc2FnZSBpbg0KPiA+PiB0aGUgcmVzZXJ2ZWQgcmFu Z2UgaXMgbm90IG5lY2Vzc2FyaWx5IGRpc2NhcmRlZCkuDQo+ID4NCj4gPiBFdmVuIGlmIHRoZSBz YW1lIGhvc3QgdHJhbnNwb3J0IGFkZHJlc3MgaXMgdXNlZCBmb3Igb3RoZXIgcHJvdG9jb2xzLA0K PiBpbmNvbWluZyBwYWNrZXRzIHRvIHRoZSBUVVJOIGNoYW5uZWwgY2FuIGJlIGlkZW50aWZpZWQg YnkganVzdCBleGFtaW5pbmcNCj4gdGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBwYWNrZXQuDQo+ ID4gTWF5IGJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmcsIEkgZGlkIG5vdCBnZXQgYSBwcm9ibGVt ID8NCj4gDQo+IEl0IHdhcyBqdXN0IGFuIGF0dGVtcHQgdG8gbWFrZSBUVVJOIGltcGxlbWVudGVy cyBhd2FyZSBvZiB0aGUgZGVtdXgNCj4gaXNzdWVzLg0KDQpHb3QgaXQsIGFkZGVkIHRoZSBmb2xs b3dpbmcgbGluZToNClRoZSBhbGdvcml0aG0gb2YgZGVtdWx0aXBsZXhpbmcgcGFja2V0cyByZWNl aXZlZCBmcm9tDQptdWx0aXBsZSBwcm90b2NvbHMgaXMgZGlzY3Vzc2VkIGluIFtSRkM3OTgzXS4N Cg0KPiANCj4gPg0KPiA+Pg0KPiA+PiAtIFNlY3Rpb24gMi4yLCBmaXJzdCBwYXJhZ3JhcGg6DQo+ ID4+DQo+ID4+IEkgdGhpbmsgdGhhdCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDc2 MzUgbWF5IGJlIHVzZWZ1bA0KPiA+PiB0aGVyZSwgYXMgYWx0ZXJuYXRpdmUgdG8gdGhlIFNUVU4g YXV0aGVudGljYXRpb24gbWVjaGFuaXNtLg0KPiA+DQo+ID4gWWVzLCB1cGRhdGVkLg0KPiA+DQo+ ID4+DQo+ID4+IC0gU2VjdGlvbiAyLjk6DQo+ID4+DQo+ID4+IFRoZSB3aG9sZSAyLjkgc2VjdGlv biBhbmQgc3Vic2VjdGlvbnMgbG9va3Mgbm9ybWF0aXZlIGFuZCBzbyBzaG91bGQNCj4gPj4gYmUg bW92ZWQgYWZ0ZXIgc2VjdGlvbiAzLCBwZXJoYXBzIG9uIHRoZWlyIG93biB0b3AgbGV2ZWwgc2Vj dGlvbi4NCj4gPg0KPiA+IERvbmUuDQo+ID4NCj4gPj4NCj4gPj4gLSBTZWN0aW9uIDQsIDR0aCBw YXJhZ3JhcGg6DQo+ID4+DQo+ID4+IEkgd291bGQgcmVwbGFjZSAiRm9yIGVhY2ggYWxsb2NhdGlv bi4uLiIgYnkgIkZvciBlYWNoIEFsbG9jYXRlDQo+ID4+IHJlcXVlc3QuLi4iLCBiZWNhdXNlIG9m IHRoZSBkdWFsIGFsbG9jYXRpb24gZmVhdHVyZS4NCj4gPg0KPiA+IEZpeGVkLg0KPiA+DQo+ID4+ DQo+ID4+IC0gU2VjdGlvbiA0LCAxMnRoIHBhcmFncmFwaDoNCj4gPj4NCj4gPj4gU2hvdWxkIG1h a2UgY2xlYXIgY2xlYXIgdGhhdCBVRFAgY292ZXJzIGFsc28gRFRMUy4NCj4gPg0KPiA+IFllcywg dXBkYXRlZC4NCj4gPg0KPiA+Pg0KPiA+PiAtIFNlY3Rpb24gNi4xLCAybmQgcGFyYWdyYXBoOg0K PiA+Pg0KPiA+PiBJZiB0aGUgcG9ydCBpcyBtdWx0aXBsZXhlZCB3aXRoIG90aGVyIHByb3RvY29s cyAoUlRQLCBXZWJSdGMsIGV0Yy4uKQ0KPiA+PiB0aGVuIGl0IGhhcyB0byByZXVzZSBhbiBleGlz dGluZyBzb2NrZXQuICBUaGUgZG9jdW1lbnQgc2hvdWxkIGV4cGxhaW4gdGhpcy4NCj4gPg0KPiA+ IEl0J3MgYWxyZWFkeSBjb3ZlcmVkIGluIFNlY3Rpb24gMi4xIChsYXN0IHBhcmFncmFwaCkuDQo+ ID4NCj4gPj4NCj4gPj4gLSBTZWN0aW9uIDYuMiwgM3RoIHBhcmFncmFwaDoNCj4gPj4NCj4gPj4g SXMgaXQgdGltZSB0byByZWNvbW1lbmQgRFRMUyBpbnN0ZWFkIG9mIFVEUD8gIEluIHRoYXQgY2Fz ZSB3ZSBuZWVkIHRvDQo+ID4+IG1ha2UgRFRMUyBtYW5kYXRvcnkgaW4gc2VjdGlvbiA0IHBhcmFn cmFwaCAxMSAoYW5kIEkgc3VwcG9ydCB0aGF0DQo+IGNoYW5nZSkuDQo+ID4NCj4gPiBObywgRFRM UyBoYXMgYm90aCBhZHZhbnRhZ2VzIChlLmcuIGRpY3Rpb25hcnkgYXR0YWNrKSAgYW5kIGRpc2Fk dmFudGFnZXMNCj4gKGUuZy4gZG91YmxlIGVuY3J5cHRpb24gb2YgYXBwbGljYXRpb24gZGF0YSku DQo+IA0KPiBPSy4NCj4gDQo+ID4NCj4gPj4NCj4gPj4gLSBTZWN0aW9uIDYuNCwgc2Vjb25kIGJ1 bGxldDoNCj4gPj4NCj4gPj4gUmVwbGFjZSAiLi4uU1JWIHByb2NlZHVyZXMpLiIgd2l0aCAiLi4u RE5TIHJlc29sdXRpb24gcHJvY2VkdXJlcykuIg0KPiA+DQo+ID4gQW55IHNwZWNpZmljIHJlYXNv biBmb3IgdGhlIHJlcGxhY2VtZW50ID8NCj4gDQo+IFRoaXMgaXMgdG8gbm90IGV4Y2x1ZGUgTlBB VFIgcHJvY2VkdXJlcyAoUkZDIDU5MjgpLg0KDQpVcGRhdGVkIHNlY29uZCBidWxsZXQuDQoNCkNo ZWVycywNCi1UaXJ1DQoNCj4gDQo+ID4NCj4gPj4NCj4gPj4gLSBTZWN0aW9ucyAxNCwgMTUgYW5k IDE2Og0KPiA+Pg0KPiA+PiBUaGVzZSBhcmUgbm8gbG9uZ2VyIG5ldyBtZXRob2RzIGFuZCBhdHRy aWJ1dGVzLiAgU2VlIGFsc28gdGhlIG5leHQNCj4gPj4gY29tbWVudC4NCj4gPg0KPiA+IEZpeGVk Lg0KPiA+DQo+ID4+DQo+ID4+IC0gU2VjdGlvbiAxOToNCj4gPj4NCj4gPj4gSGVyZSB5b3UgbmVl ZCB0byB1cGRhdGUgdGhlIGV4aXN0aW5nIG1ldGhvZHMsIGF0dHJpYnV0ZXMgYW5kIGVycm9yDQo+ ID4+IGNvZGUgc28gdGhlIElBTkEgcmVnaXN0cmllcyBwb2ludCB0byB0aGUgUkZDLXRvLWJlLCB0 aGVuIHlvdSByZXF1ZXN0DQo+ID4+IGFsbG9jYXRpb24gZm9yIHRoZSBuZXcgYXR0cmlidXRlcy4g IFNlZSBzZWN0aW9uIDE3IG9mIFNUVU5iaXMgb24gYQ0KPiA+PiB3YXkgdG8gZG8gdGhhdCAodGhh dCB3YXMgZG9uZSBmb2xsb3dpbmcgYSBkaXNjdXNzaW9uIHdpdGggdGhlIElBTkENCj4gcmVwcmVz ZW50YXRpdmUgYXQgYW4gSUVURiBtZWV0aW5nKS4NCj4gPg0KPiA+IFRoYW5rcywgdXBkYXRlZCBk cmFmdC4NCj4gPg0KPiA+Pg0KPiA+PiBOb3RlIHRoYXQgSUNNUCBzaG91bGQgYmUgY29tcHJlaGVu c2lvbi1tYW5kYXRvcnksIG5vdCBvcHRpb25hbCwgYXMNCj4gd2UNCj4gPj4gZG8gbm90IHdhbnQg YW4gb2xkIGNsaWVudCB0byByZWplY3QgYSBEYXRhIGluZGljYXRpb24gd2l0aCBhbiBJQ01QIGF0 dHJpYnV0ZS4NCj4gPg0KPiA+IElmIHRoZSBpbmRpY2F0aW9uIGNvbnRhaW5zIHVua25vd24gY29t cHJlaGVuc2lvbi1yZXF1aXJlZCBhdHRyaWJ1dGVzLCB0aGUNCj4gYmVoYXZpb3IgaXMgdGhlIGlu ZGljYXRpb24gaXMgZGlzY2FyZGVkIGFuZCBwcm9jZXNzaW5nIGNlYXNlcy4NCj4gPg0KPiA+Pg0K PiA+PiBBbHNvLCBJIGRvIG5vdCBrbm93IHdoYXQgdGhpcyBTZW5kRXJyIG1ldGhvZCBpcy4NCj4g Pg0KPiA+IFJlbW92ZWQgU2VuZEVyciAoc3RhbGUgZW50cnkgZnJvbSBhIHByZXZpb3VzIHZlcnNp b24gb2YgdGhlIGRyYWZ0KS4NCj4gPg0KPiA+Pg0KPiA+Pg0KPiA+PiBOaXRzDQo+ID4+IC0tLS0N Cj4gPj4NCj4gPj4gU2VjdGlvbiAxOg0KPiA+Pg0KPiA+PiBzL2Nvbm5lY3Rpb24gdG8gdGhlIElu dGVybmV0IC4vY29ubmVjdGlvbiB0byB0aGUgSW50ZXJuZXQuLw0KPiA+Pg0KPiA+PiBTZWN0aW9u IDIuNCwgZmlyc3QgcGFyYWdyYXBoOg0KPiA+Pg0KPiA+PiBUaGUgdGV4dCBzd2l0Y2hlcyBiZXR3 ZWVuIHRoZSB3b3JkcyAibWVjaGFuaXNtcyIgYW5kICJ3YXkiLiAgQ2hvb3NlDQo+ID4+IG9uZS4N Cj4gPj4NCj4gPj4gU2VjdGlvbiA2LjIsIGl0ZW0gODoNCj4gPj4NCj4gPj4gcy9BRERJVElPTkFM LSBBRERSRVNTLUZBTUlMWS9BRERJVElPTkFMLUFERFJFU1MtRkFNSUxZLw0KPiA+Pg0KPiA+PiBT ZWN0aW9uIDEyLjEsICJQcmVmZXJyZWQgQmVoYXZpb3IiDQo+ID4+DQo+ID4+IHMvTGFiZWwgRmll bGRbUkZDMzY5N10vTGFiZWwgRmllbGQgW1JGQzM2OTddLw0KPiA+Pg0KPiA+PiBTZWN0aW9uIDIx Og0KPiA+Pg0KPiA+PiBzL0FERFJFU1MtRVJSUi1DT0RFL0FERFJFU1MtRVJSLUNPREUvDQo+ID4+ DQo+ID4+IFNlY3Rpb24gMjI6DQo+ID4+DQo+ID4+IHMvb3JnaW5hbC9vcmlnaW5hbC8NCj4gPg0K PiA+IFRoYW5rcywgZml4ZWQgYWxsIGFib3ZlIG5pdHMuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4g LVRpcnUNCj4gPg0KPiA+Pg0KPiANCj4gDQo+IA0KPiAtLQ0KPiBNYXJjIFBldGl0LUh1Z3Vlbmlu DQo+IEVtYWlsOiBtYXJjQHBldGl0LWh1Z3VlbmluLm9yZw0KPiBCbG9nOiBodHRwczovL21hcmMu cGV0aXQtaHVndWVuaW4ub3JnDQo+IFByb2ZpbGU6IGh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9p bi9wZXRpdGh1Zw0KDQo= From nobody Sun Feb 11 22:19:07 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7192124BE8; Sun, 11 Feb 2018 22:19:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151841634170.8216.3069161614615491685@ietfa.amsl.com> Date: Sun, 11 Feb 2018 22:19:01 -0800 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-turnbis-13.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 06:19:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized WG of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-13.txt Pages : 83 Date : 2018-02-11 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. This document obsoletes [RFC5766] and [RFC6156]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-turnbis-13 https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 11 22:27:19 2018 Return-Path: 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 ACA84126C26 for ; Sun, 11 Feb 2018 22:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 zVb2de5Hguhx for ; Sun, 11 Feb 2018 22:27:17 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F21124BE8 for ; Sun, 11 Feb 2018 22:27:16 -0800 (PST) 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=1518416835; h=From: To: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-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=+ zSYwvSqE5K8VCRYVdP1ujPSMQl3MUK+BPk+4ja8Cs g=; b=fDc7CvL4Ngg48LDtBFQEhHfqupU7Cv4GMaS2YlG/08MG mcaNpDPzz92cdrbC+YDHom1AKRZW0gVt6X1cJjELQPRrE/VMiX 1HqZ76BNQ1pfJK1UTuKaUYLqz2GZ+ekZuIMb4EEFAGgV6F48bw 0hM+PA1tqgDGMQrEeys8xJY6Peg= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 7c5a_1291_afacc9ea_5790_4ed8_96e5_c0598da56f80; Mon, 12 Feb 2018 00:27:15 -0600 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 12 Feb 2018 01:27:14 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 12 Feb 2018 01:27:14 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 12 Feb 2018 01:27:13 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1434.namprd16.prod.outlook.com (10.173.210.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Mon, 12 Feb 2018 06:27:12 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0485.015; Mon, 12 Feb 2018 06:27:12 +0000 From: "Konda, Tirumaleswar Reddy" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-13.txt Thread-Index: AQHTo8l9oWMiYfXbK0WuhGIbwqVKMaOgTTFw Date: Mon, 12 Feb 2018 06:27:12 +0000 Message-ID: References: <151841634170.8216.3069161614615491685@ietfa.amsl.com> In-Reply-To: <151841634170.8216.3069161614615491685@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1434; 7:f7z+lwbn4oWj5SRV+nCofc5sq85n9wd4OA/DezgsRRqv5EnQhVoxJAZzh/XtfJ7QP5L1vQpBWdGW/SwGxI7FaHFW+8ZKkHSU0o+N2SLSuoAvD18jxEI/NcuEdpMUcOE+UXP8LgIFgBa8vtQ/F5dgxvrB6/ELGS+8Cewlj1rvMeu1UhnP24tBtmftwogo69mNhpGLV4bQSnjEa74OJGknqC61QNOazzJ0PoM7g9GemjcgVByRW2qOofqTnadEi3Hx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7484f83a-b145-4ed8-a0c9-08d571e1a6d1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1434; x-ms-traffictypediagnostic: DM5PR16MB1434: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231101)(2400082)(944501161)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1434; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1434; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(346002)(376002)(366004)(39850400004)(32952001)(189003)(199004)(13464003)(377424004)(3660700001)(74316002)(229853002)(3280700002)(102836004)(106356001)(53546011)(6246003)(66066001)(6506007)(2900100001)(316002)(105586002)(97736004)(6116002)(26005)(80792005)(3846002)(86362001)(186003)(2906002)(33656002)(6436002)(68736007)(77096007)(8676002)(81166006)(76176011)(5640700003)(25786009)(9686003)(53936002)(1730700003)(81156014)(8936002)(2351001)(478600001)(6916009)(2950100002)(2501003)(6306002)(305945005)(966005)(14454004)(5660300001)(99286004)(7696005)(7736002)(72206003)(55016002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1434; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 0SecANXdAV05Z9kZgICeYpUm/8xaC5LO5RsKFESl6xW9VsuTcAki9CLhEWcfq7Wbm2lZKGL1Sq698/vVvbETcg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7484f83a-b145-4ed8-a0c9-08d571e1a6d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 06:27:12.2348 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1434 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6219> : inlines <6389> : streams <1778739> : uri <2591306> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-13.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 06:27:19 -0000 This revision addresses comments from Brandon and Marc. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, February 12, 2018 11:49 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-13.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized WG of the > IETF. >=20 > Title : Traversal Using Relays around NAT (TURN): Relay= Extensions > to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-13.txt > Pages : 83 > Date : 2018-02-11 >=20 > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. >=20 > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. >=20 > This document obsoletes [RFC5766] and [RFC6156]. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tram-turnbis-13 > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Sat Feb 17 21:41:06 2018 Return-Path: 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 3F59E12426E for ; Sat, 17 Feb 2018 21:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 xpy86HWuSKFi for ; Sat, 17 Feb 2018 21:41:02 -0800 (PST) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897F0124235 for ; Sat, 17 Feb 2018 21:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=103xbbC5YC6rpoxF8uo4/VYJ/xOOnjZxgQRNC/MVidw=; b=HvDV4ieB+SjjAQMhTuxJ21RPHotCSRULOZ+++sPuKWWg/FvPm4A3qXKvjnJPnQofDxY0ugMF0ne94zKSanPUnrVOqgcKN/zJsR8ie8//3+7QP1y27yywZR/WMXkW5IIJBqixLsW8fwI8OcbeP69kjw4mstlOjnGW6856tPuym9U= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0178.outbound.protection.outlook.com [216.32.180.178]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-186-Rwi37nvuPFaoJc6MM4VPTw-1; Sun, 18 Feb 2018 00:40:58 -0500 Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB3128.namprd03.prod.outlook.com (10.171.245.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Sun, 18 Feb 2018 05:40:55 +0000 Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::4499:4345:1b21:90b8]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::4499:4345:1b21:90b8%13]) with mapi id 15.20.0506.021; Sun, 18 Feb 2018 05:40:55 +0000 From: "Asveren, Tolga" To: Marc Petit-Huguenin , Marc Petit-Huguenin , "Gonzalo Salgueiro (gsalguei@cisco.com)" , "tram@ietf.org" Thread-Topic: draft-ietf-tram-stun-pmtud-06 review Thread-Index: AdOoeuWqoyIVbPnJTkKqVXoa0q8HIQ== Date: Sun, 18 Feb 2018 05:40:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.251.142] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR03MB3128; 7:Mv2fXV/CBsrxhJKrZVZNDm0/UxHc1ylys8h4f6X+x739ANddBfSueAlVJvqTHpHN43EFoIuzLD3bZazuuo6bfk9s9VdSPrHZ+BI4nUrlpgm9DdpAZPLQQTQwLEYOvfaBwldRWNVUgumbOHtGrJorksm3pc5XWAwIwX1y6tW9Ci0BG26bBci0tiyBiPXMtYb64Sd/T6iOI+5EBHod6fzU6AeeWKCQaO87lPKgHN7WkJYMxvmDe+qFG7DB44zRPXup; 20:Um4RzsmB2kv1xnQCLCPJ4SWRnCDekHyPYAvTQrM2WZg10r8Qsf5++Z4AfiJ2O5Knu8XryIACHbslYj8Uptl4rR8lHEvxMkwN0bCn/1yoWRkEYI2iC+Ss71g8kKNvL/dACyEDZCxuYGK0/9qRPp6tjo6omlePwFXJ723kCsH+BpQ= x-ms-office365-filtering-correlation-id: a2d7fe9a-0664-4006-853d-08d576922e1d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR03MB3128; x-ms-traffictypediagnostic: CY4PR03MB3128: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231101)(944501161)(93006095)(93001095)(6041288)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR03MB3128; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB3128; x-forefront-prvs: 058707456E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(376002)(346002)(39850400004)(396003)(189003)(199004)(2906002)(5250100002)(81166006)(81156014)(14454004)(97736004)(8676002)(966005)(106356001)(3660700001)(478600001)(5660300001)(3280700002)(55016002)(68736007)(9686003)(25786009)(6116002)(8936002)(2501003)(3846002)(53936002)(6436002)(6306002)(2900100001)(74316002)(7736002)(7696005)(305945005)(110136005)(316002)(86362001)(59450400001)(6506007)(33656002)(26005)(102836004)(186003)(105586002)(66066001)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB3128; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-microsoft-antispam-message-info: w9DvWo0c7NTJNeZ2PhmphHpFSnhHQXRxNyvir7UK2NyeTArXPFniYC5afMvnbXMm2z6TydhsugAoKddlZ8eHPL/wdEPTg/9HqBeQabA5XDxQl0Q6evBWc4hd2JDxLChS9uxjp8+IQVN3EOyawB6Ecd7erptFibyqnGnvSZNoOK8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2d7fe9a-0664-4006-853d-08d576922e1d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2018 05:40:55.2063 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB3128 X-MC-Unique: Rwi37nvuPFaoJc6MM4VPTw-1 Content-Type: multipart/alternative; boundary="_000_CY4PR03MB316039CC07807621C64AFE39A5C90CY4PR03MB3160namp_" Archived-At: Subject: [tram] draft-ietf-tram-stun-pmtud-06 review X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 05:41:05 -0000 --_000_CY4PR03MB316039CC07807621C64AFE39A5C90CY4PR03MB3160namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Marc, Gonzalo, Some comments/questions for draft-ietf-tram-stun-pmtud-06: i- 4. Implementations supporting this specification MUST implement the server side of both the Simple Probing mechanism (Section 4.1) and the Complete Probing mechanism (Section 4.2). Implementations supporting this specification MUST implement the client side of the Complete Probing mechanism. They MAY implement the client side of the Simple Probing mechanism. I don't see the rationale behind mandating this behavior. Such semantics in= general are taken care of in the context of a capability negotiation mecha= nism, which this document does not specify. As it stands right now, I think= this is best left to local policy and bilateral agreements and I would sug= gest not to use anything stronger than "RECOMMEND". ii- 4.1 DF bit set over UDP. =3D=3D> DF bit in IP Header. Right? (the same in 4.2) iii- 4.1.1 A client MUST NOT send a probe if it does not have knowledge that the server supports this specification. This is done either by external signalling or by a mechanism specific to the UDP protocol to which PMTUD capabilities are added or by one of the mechanisms specified in Section 5. I suggest adding text for possible use of local policy/bilateral agreements= for this purpose. iv- 4.2 Some protocols may already have a way of identifying each individual UDP packet, in which case these identifiers SHOULD be used in the IDENTIFIERS attribute of the Report Response. What is meant here as "some protocols"? Are you referring to what is carri= ed as payload of UDP or what is used below UDP? v- 4.2 In the first packet identification mechanism, the server computes a checksum over each packet received and sends back to the sender the list of checksums ordered chronologically. The client compares this list to its own list of checksums. What if there are two probes with the same checksum right after each other = and one of them is lost? How can client disambiguate such a case in the re= sponse? v- 7 The Simple Probing mechanism may be used without authentication because this usage by itself cannot trigger an amplification attack because the Probe Response is smaller than the Probe Request. Isn't the same true for Sum(Probe Requests) > (Report Response)? vii- nit =3D=3D The copyright year in the IETF Trust and authors Copyright Line does= not match the current year -- The document date (September 1, 2017) is 169 days in the past. Is thi= s intentional? Thanks, Tolga --_000_CY4PR03MB316039CC07807621C64AFE39A5C90CY4PR03MB3160namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Marc, Gonzalo,
 
Some comments/questions for draft-ietf-tram-stun-pmtud-06:
 
i- 4.
 
=   Implementations supporting this specification MUST implement the
=    server side of both the Simple Probing mechanism (Section 4.1)= and
=    the Complete Probing mechanism (Section 4.2).
=    Implementations supporting this specification MUST implement t= he
=    client side of the Complete Probing mechanism.  They MAY = implement
=    the client side of the Simple Probing mechanism.=
 
I don’t see the rationale behind mandating this behavior. Such s= emantics in general are taken care of in the context of a capability negoti= ation mechanism, which this document does not specify. As it stands right n= ow, I think this is best left to local policy and bilateral agreements and I would suggest not to use anything str= onger than “RECOMMEND”.
 
ii- 4.1
= DF bit set over UDP.
=3D=3D>
= DF bit in IP Header.
Right?  (the same in 4.2)
 
iii- 4.1.1
= A client MUST NOT send a probe if it does not have knowledge that the
=    server supports this specification.  This is done either = by external
=    signalling or by a mechanism specific to the UDP protocol to w= hich
=    PMTUD capabilities are added or by one of the mechanisms speci= fied in
=    Section 5.
I suggest adding text for possible use of local policy/bilateral agree= ments for this purpose.
 
iv-  4.2
= Some protocols may already have a way of identifying each individual=
=    UDP packet, in which case these identifiers SHOULD be used in = the
=    IDENTIFIERS attribute of the Report Response.
What is meant here as “some protocols”? Are you referring&= nbsp; to what is carried as payload of UDP or what is used below UDP?
 
v- 4.2
= In the first packet identification mechanism, the server computes a<= /font>
=    checksum over each packet received and sends back to the sende= r the
=    list of checksums ordered chronologically.  The client co= mpares this
=    list to its own list of checksums.
What if there are two probes with the same checksum right after each o= ther and one of them is lost? How can client disambiguate such a case in&nb= sp; the response?
 
v- 7
= The Simple Probing mechanism may be used without authentication
=    because this usage by itself cannot trigger an amplification a= ttack
=    because the Probe Response is smaller than the Probe Request.<= /span>
Isn’t the same true for Sum(Probe Requests) > (Report Respons= e)?
 
vii- nit
= =3D=3D The copyright year in the IETF Trust and authors Copyright Line does= not
=      match the current year
=  
=   -- The document date (September 1, 2017) is 169 days in the past.&nb= sp; Is this
=      intentional?
 
 
Thanks,
Tolga
 
 --_000_CY4PR03MB316039CC07807621C64AFE39A5C90CY4PR03MB3160namp_-- From nobody Mon Feb 19 09:30:49 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5EC126CD8; Mon, 19 Feb 2018 09:30:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley To: Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151906144357.18629.1445621426796368031@ietfa.amsl.com> Date: Mon, 19 Feb 2018 09:30:43 -0800 Archived-At: Subject: [tram] Genart last call review of draft-ietf-tram-stunbis-15 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 17:30:43 -0000 Reviewer: Dale Worley Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. Document: draft-ietf-tram-stunbis-15 Reviewer: Dale R. Worley Review Date: 2018-02-19 IETF LC End Date: 2018-02-20 IESG Telechat date: [unknown] Summary: This draft is on the right track but has open issues, described in the review. Overall, the draft is quite well organized and well written. But there are a number of open issues that have substantial technical content. I suspect that the intended design does not have these issues, and the issues that I see are just where the text hasn't been fully updated to match the intended design. Dale ---------------------------------------------------------------------- There is an issue that shows up in several places: The NAT may forward the request using an IP family that is different from the IP family that it received the request using. This means that the "source IP family of the request" may depend on whether one is speaking of the client or the server. The draft is cognizant of this, and mentions its consequences in sections 6.3.3 and 12. But this also has consequences for ALTERNATE-SERVER: Section 14.15 says "The IP address family MUST be identical to that of the source IP address of the request." even though that family might not be usable by the client. The draft doesn't seem to explicitly say that this comes from address-switching by the NAT. It would help if there was a higher-level discussion of this matter, pointing to the various consequences. The text contains these references to SHA algorithms (that it does not itself define). Some should be corrected: HMAC-SHA1 HMAC-SHA-1 should be HMAC-SHA1 per RFC 2104 HMAC-SHA256 HMAC-SHA-256 should be HMAC-SHA256 per RFC 6151, but HMAC-SHA-256 per RFC 6151! SHA1 SHA-1 It appears that the proper name of this function is SHA-1. SHA256 SHA-256 NIST calls this algorithm SHA-256. 3. Terminology This section needs to be updated to reference RFC 8174. 4. Definitions Although the definitions of STUN Client and STUN Server mention that they receive responses and requests (respectively), they don't mention that they also receive indications. 5. STUN Message Structure All STUN messages MUST start with a 20-byte header followed by zero or more Attributes. It would be clearer, I think, to say "All STUN messages comprise a 20-byte header followed by zero or more Attributes." 6.2.2. Sending over TCP or TLS-over-TCP The client MAY send multiple transactions over a single TCP (or TLS- over-TCP) connection, and it MAY send another request before receiving a response to the previous. s/the previous./the previous request./ This section should also state whether or not a server is allowed to provide responses in a different order than it received the requests, if it receives further requests before sending a response. o if multiplexing other application protocols over that port, has finished using that other application, and s/that other application/that other protocol/ 6.3.4. Processing an Error Response o If the error code is 300 through 399, the client SHOULD consider the transaction as failed unless the ALTERNATE-SERVER extension is being used. See Section 10. This syntax binds "section 10" to the entire preceding sentence, whose topic is error codes 300-399, whereas "section 10" only applies to ALTERNATE-SERVER. A better syntax would be o If the error code is 300 through 399, the client SHOULD consider the transaction as failed unless the ALTERNATE-SERVER extension (Section 10) is being used. 9.2. Long-Term Credential Mechanism Note that the long-term credential mechanism cannot be used to protect indications, since indications cannot be challenged. Usages utilizing indications must either use a short-term credential or omit authentication and message integrity for them. Alternatively, if there has been a recent request transaction between the client and the server, then a nonce have been established, and an indication can be sent securely using the long-term mechanism. (Although there is no mechanism for signaling if the nonce has become stale.) It seems to me plausible that some usage may wish to exploit this possibility. 9.2.1. Bid Down Attack Prevention To indicate that it supports this specification, a server MUST prepend the NONCE attribute value with the character string composed of "obMatJos2" concatenated with the Base64 [RFC4648] encoding of the 24 bit STUN Security Features as defined in Section 17.1. It might be informative to note that the encoding of the security features is always four characters long: s/the Base64 [RFC4648] encoding/the (4 character) Base64 [RFC4648] encoding/ 9.2.2. HMAC Key The structure of the key when used with long-term credentials facilitates deployment in systems that also utilize SIP. Typically, SIP systems utilizing SIP's digest authentication mechanism do not actually store the password in the database. Presumably there should be an explicit reference [RFC3261] here. 9.2.3. Forming a Request This section defines "first request from the client to the server" as being "identified by its IP address and port". However in section 9.2.3.1, "the server" is "identified by hostname, if the DNS procedures of Section 8 are used, else IP address if not". These are not the same, and presumably need to be aligned on the correct definition. (And perhaps one section can simply refer to the definition in the other section.) Alternatively, they may be intended to be different, in which case the text needs to be clarified and also warn the reader. 9.2.3.1. First Request In other words, the very first request is sent [...] It seems better style to omit "very", given that "first request" has a specific meaning. 9.2.4. Receiving a Request The server MUST ensure that the same NONCE cannot be selected for clients that use different source IP addresses, different source ports, or both different source IP addresses and source ports. It seems clearer to phrase this condition "The server MUST NOT choose the same NONCE for two requests unless they have the same source IP address and port." o If the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithm" bit set to 1 but PASSWORD-ALGORITHMS does not match the value sent in the response that sent this NONCE, then the server MUST generate an error response with an error code of 400 (Bad Request). o If the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithm" bit set to 1 but the request contains neither PASSWORD-ALGORITHMS nor PASSWORD- ALGORITHM, then the request is processed as though PASSWORD- ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS attribute did not contain MD5, this will result in a 400 Bad Request in a later step below). o If the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithm" bit set to 1 but only one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then the server MUST generate an error response with an error code of 400 (Bad Request). o If the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithm" bit set to 1 but PASSWORD-ALGORITHM does not match one of the entries in PASSWORD- ALGORITHMS, then the server MUST generate an error response with an error code of 400 (Bad Request). Given these cases all include one long condition, it seems like it would be clearer if they were grouped and the condition factored out: o If the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithm" bit set to 1, the server performs these checks in the order specified: * If PASSWORD-ALGORITHMS does not match the value sent in the response that sent this NONCE, then the server MUST generate an error response with an error code of 400 (Bad Request). * If the request contains neither PASSWORD-ALGORITHMS nor PASSWORD- ALGORITHM, then the request is processed as though PASSWORD- ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS attribute did not contain MD5, this will result in a 400 Bad Request in a later step below). * If only one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then the server MUST generate an error response with an error code of 400 (Bad Request). * If PASSWORD-ALGORITHM does not match one of the entries in PASSWORD- ALGORITHMS, then the server MUST generate an error response with an error code of 400 (Bad Request). This could be further shortened and clarified by using the negation of the condition we desire: o If the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithm" bit set to 1, the server performs these checks in the order specified: * If the request contains neither PASSWORD-ALGORITHMS nor PASSWORD- ALGORITHM, then the request is processed as though PASSWORD- ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS attribute did not contain MD5, this will result in a 400 Bad Request in a later step below). * Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD-ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches the value sent in the response that sent this NONCE, and (3) PASSWORD-ALGORITHM matches one of the entries in PASSWORD-ALGORITHMS, the server MUST generate an error response with an error code of 400 (Bad Request). -- Servers can invalidate nonces in order to provide additional security. It's not clear what "invalidate" means here. The text has been talking about nonces expiring, which suggests that it is not a process that the server actively causes at the time the nonce becomes invalid, but "invalidate" suggests that the server causes it at the moment of invalidation. See Section 4.3 of [RFC7616] for guidelines. There is no section 4.3 in RFC 7616. 9.2.5. Receiving a Response If the test succeeds and the "nonce cookie" has the STUN Security Feature "Username anonymity" bit set to 1 but no USERHASH attribute is present, then the client MUST NOT retry the request with a new transaction. I can find no reference to the server sending USERHASH in a response, so I don't understand what this means. I think what was intended is "... is set to 1, then the client MUST NOT retry the request using the USERHASH attribute." But that requirement seems to be stated in the next paragraph: If the response is an error response with an error code of 401 (Unauthenticated), the client SHOULD retry the request with a new transaction. [...] If the "nonce cookie" was present and had the STUN Security Feature "Username anonymity" bit set to 1 then the USERHASH attribute MUST be used, else the USERNAME attribute MUST be used. -- For all other responses, if the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "User anonymity" bit set to 1 but USERHASH is not present, the response MUST be ignored. As above. The above texts suggest that there is, or was, an intention that the server would reflect back the USERHASH value in responses. But checking all the mentions of "USERHASH", I can find no text saying that USERHASH will ever appear in responses. This design decision needs to be verified and the text updated correspondingly. If the response is an error response with an error code of 400, and does not contains either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- SHA256 attribute then the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue. Some responses generated according to this specification will not pass the above check. E.g., from section 9.2.4 item 2: o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- INTEGRITY-SHA256 attribute, but is missing either the USERNAME or USERHASH, REALM, or NONCE attribute, the server MUST generate an error response with an error code of 400 (Bad Request). This response SHOULD NOT include a USERNAME, USERHASH, NONCE, or REALM. The response cannot contain a MESSAGE-INTEGRITY or MESSAGE- INTEGRITY-SHA256 attribute, as the attributes required to generate them are missing. How does the client effectively receive the error response in this situation? 10. ALTERNATE-SERVER Mechanism To be clearer, the first paragraph should mention that the ALTERNATE-SERVER attribute carries an IP address, not a domain name (see section 14.15). In particular, that disambiguates the test for "same server" in the last paragraph. The error response message MAY be authenticated; however, there are uses cases for ALTERNATE-SERVER where authentication of the response is not possible or practical. s/uses cases/use cases/ If the client has been redirected to a server on which it has already tried this request within the last five minutes, [...] It is a little more formal to say "to a server to which it has already sent this request ...". 11. Backwards Compatibility with RFC 3489 Any STUN request or indication without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST always result in an error. The meaning is clear, but in this document, "error" seems to be limited to error responses. Perhaps better is: Any STUN request or indication without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST be considered invalid: requests MUST generate error responses and indications MUST be ignored. Also, what error code should be used? 13. STUN Usages A usage would also define: I'm sure you don't want to use the subjunctive mood here, so perhaps s/would/will/. OTOH, you might want to s/would/must/, or "A usage also defines:" to parallel the first sentence of the paragraph. 14. STUN Attributes Note that there is an important ordering restriction on attributes: the attributes MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256, and FINGERPRINT must, if present, appear finally and in that order. There also seems to be a rule that any attributes which follow one of these attributes in violation of that rule MUST be ignored. This is described in those attribute definitions, but it's a global constraint in the use of attributes, and I think should be pointed out at this level of the specification. I'm nervous about the "must be ignored" rule, as it becomes a little complicated to do the processing right in all cases. Perhaps it would be better to declare that any such violation invalidates the message instead? 14.3. USERNAME The value of USERNAME is a variable-length value. This doesn't actually say what the value is. Better: The value of USERNAME is a variable-length value containing the authentication username. 14.5. MESSAGE-INTEGRITY Since it uses the SHA1 hash, the HMAC will be at 20 bytes. I think "at" should be omitted. The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE- INTEGRITY attribute. With the exception of the MESSAGE-INTEGRITY- SHA256 and FINGERPRINT attributes, which appear after MESSAGE- INTEGRITY, agents MUST ignore all other attributes that follow MESSAGE-INTEGRITY. This paragraph is troublesome. The matter of attribute ordering is discussed above under section 14. But the description of calculating the MAC disagrees with the description in the fourth paragraph. My suspicion is that the fourth paragraph is correct. My choice would be to omit this paragraph and leave its topics to be dealt with elsewhere. Based on the rules above, the hash used to construct MESSAGE- INTEGRITY includes the length field from the STUN message header. Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be inserted into the message (with dummy content). The length MUST then be set to point to the length of the message up to, and including, the MESSAGE-INTEGRITY attribute itself, but excluding any attributes after it. Once the computation is performed, the value of the MESSAGE-INTEGRITY attribute can be filled in, and the value of the length in the STUN header can be set to its correct value -- the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY, the length field should be adjusted to point to the end of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC. Such adjustment is necessary when attributes, such as FINGERPRINT, appear after MESSAGE-INTEGRITY. I would rephrase this slightly, borrowing from the second paragraph: The text used as input to HMAC is the STUN message, up to and including the MESSAGE-INTEGRITY attribute. The length field of the STUN message header is adjusted to point to the end of the MESSAGE-INTEGRITY attribute. The value of the MESSAGE-INTEGRITY attribute is set to the dummy value ***. Once the computation is performed, the value of the MESSAGE-INTEGRITY attribute is filled in, and the value of the length in the STUN header is set to its correct value -- the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY, the length field must be adjusted to point to the end of the MESSAGE-INTEGRITY attribute and the value of the attribute set to *** prior to calculating the HMAC. Such adjustment is necessary when attributes, such as FINGERPRINT, appear after MESSAGE-INTEGRITY. Also, the text doesn't specify what the "dummy content" is! 14.6. MESSAGE-INTEGRITY-SHA256 This section has the same problems regarding the HMAC calculation as section 14.5. The discussion of truncation seems to assume that the reader already fully understands the concept. Better would be to explain it explicitly, since that doesn't take more words: The MESSAGE-INTEGRITY-SHA256 attribute can be present in any STUN message type. The MESSAGE-INTEGRITY-SHA256 attribute contains an initial portion of the HMAC-SHA-256 [RFC2104] of the STUN message. The value will be at most 32 bytes and MUST be a positive multiple of 4 bytes. The value must be the full 32 bytes unless the STUN usage explicitly specifies that truncation is allowed. Usages may specify a minimum length longer than 4 bytes. 14.7. FINGERPRINT The FINGERPRINT attribute MAY be present in all STUN messages. The value of the attribute is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself, [...] Note that unlike the MESSAGE-INTEGRITY attributes, the FINGERPRINT calculation does not prepare the text by adjusting the Length field of the header. Verify that this is what is intended and perhaps mention it explicitly. [...] up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with the 32-bit value 0x5354554e (the XOR helps in cases where an application packet is also using CRC-32 in it). This is awkward. Perhaps unpack it into: The value of the attribute is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with the 32-bit value 0x5354554e. (The XOR operation ensures that the FINGERPRINT test will not report a false positive on a packet containing a CRC-32 generated by an application protocol.) 14.8. ERROR-CODE The Reserved bits SHOULD be 0, and are for alignment on 32-bit boundaries. Receivers MUST ignore these bits. The Class represents the hundreds digit of the error code. The value MUST be between 3 and 6. The Number represents the error code modulo 100, and its value MUST be between 0 and 99. How is Number encoded? I suspect that binary is intended, but it is an 8-bit field holding a two-digit decimal number, and so might plausibly be encoded as two nibbles containing the two digits. 14.9. REALM Presence in certain error responses indicates that the server wishes the client to use a long-term credential for authentication. I think you mean s/a long-term credential/a long-term credential in that realm/. 14.10. NONCE Note that this means that the NONCE attribute will not contain actual quote characters. More exactly, "will not contain the surrounding quote characters". But some thought should be given to using the same wording in 14.9 and 14.10. 14.11. PASSWORD-ALGORITHMS The parameters start with the actual length of the parameters as a 16-bit value, followed by the parameters that are specific to each algorithm. "actual length" should be "length (prior to padding)". 14.12. PASSWORD-ALGORITHM The parameters starts with the actual length of the parameters as a 16-bit value, followed by the parameters that are specific to the algorithm. "actual length" should be "length (prior to padding)". 15.1.2. Inside Attacks Fortunately, STUN requests can be processed statelessly by a server, making such attacks hard to launch. Actually, such attacks are easy to launch, but "hard to launch effectively". This attack is mitigated by ingress source address filtering. I would help to explain who is filtering and on what basis to implement this mitigation. 15.2.4. Attack IV: Eavesdropping In this attack, the attacker forces the client to use a reflexive address that routes to itself. "itself" usually refers to the subject of the verb in its clause, which is "address". But I think "attacker" is intended, in which case you can phrase it "that routes to the attacker itself". 17.1. STUN Security Features Registry New Security Features are assigned by a Standard Action [RFC8126]. s/Standard Action/Standards Action/ per RFC 8u126 section 4.9. 17.3.2. New Attributes 0xXXXX: PASSSORD-ALGORITHMS s/PASSSORD/PASSWORD/ 17.5. Password Algorithm Registry I think you want to title this registry "Stun password algorithm registry". 17.6. STUN UDP and TCP Port Numbers This section should state that it is updating "Service Name and Transport Protocol Port Number Registry". 18. Changes since RFC 5389 The following items should contain proper references to the mentioned RFCs: o Added support for DTLS-over-UDP (RFC 6347). o Aligned the RTO calculation with RFC 6298. o Added support for STUN URI (RFC 7064). o Updated the PRECIS support to RFC 8265. [END] From nobody Wed Feb 21 12:21:28 2018 Return-Path: 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 78EB212D94A; Wed, 21 Feb 2018 12:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 aVEd2pCV6Zbo; Wed, 21 Feb 2018 12:21:25 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6525A12DA00; Wed, 21 Feb 2018 12:21:25 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1LKHYKj010197; Wed, 21 Feb 2018 20:21:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : subject : to : cc : references : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=KVxgTQZizQF3chVRbBTMlYQsfQBWSpBdn1KGh/oWfzE=; b=Sn04B7ElL0Dwy9OVgXWJm9Lwf5v9sTl7Hh174NUY90HU2AUG5xu6IF3vlK8RUaGnoWLF T8EDXWaRf88K3Z8+QBqog7MIr60Mi++bjnGbXGMfydY1PxQ4Z+KclwWHzKVEMPyITk8p mh+YRtenfwHWnXDNKBnxEjIsdSSsn6R/1lw5M8hrWhVEDMt+Q5Ieokgz8o+7KZc88mC2 f+GinkmN9W/2r3Mum8F7nyJqYAK/f4Pt5u5zLr6cnTe/hPqp/F0OvvHCfm6hefQiv+tf xVdiiOL9oFoCJG4EXyJcXu8vp/JrMvqxlZ/BbTCzwzzrUozaeCMgkLWHDyiwJgcsMdOo QQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2g8vn2306j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Feb 2018 20:21:24 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1LKL73j020768; Wed, 21 Feb 2018 15:21:23 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2g6gm1kjj8-1; Wed, 21 Feb 2018 15:21:23 -0500 Received: from [172.28.119.246] (bowill.kendall.corp.akamai.com [172.28.119.246]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id B153D20066; Wed, 21 Feb 2018 20:21:22 +0000 (GMT) From: Brandon Williams To: "Konda, Tirumaleswar Reddy" , "tram@ietf.org" Cc: "draft-ietf-tram-turnbis@ietf.org" References: <150874106330.24567.10025213746592540332@ietfa.amsl.com> <61866009-27d0-bdce-815f-7905d69cd661@akamai.com> Message-ID: Date: Wed, 21 Feb 2018 15:20:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-21_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802210243 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-21_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802210242 Archived-At: Subject: [tram] Review of draft-ietf-tram-turnbis-13.txt (was Re: I-D Action: draft-ietf-tram-turnbis-12.txt) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 20:21:27 -0000 Hi Tiru, Most of my comments have been addressed with this update. There are still a few issues raised by idnits, two of which are errors. == start idnits === Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6156], [RFC5766]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC6156, but th abstract doesn't seem to directly say this. It does mention RFC6156 though, so this could be OK. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0x4001' is mentioned on line 662, but not defined ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) == end idnits === Based on the above. * The RFC mentions in the abstract should not be links. Please remove the xref tags and replace with simple textual references. From the look of stunbis, which doesn't use xref tags, the HTML doc system appears to turn them into hyperlinks anyway, which is weird. Nevertheless, doing it the way you did generates an error from idnits and errors should really be corrected. * I think the point about IPv6 documentation addresses is just because something about the formatting is causing it not to matching against the small number of them in section 19.4. That said, IPv6 documentation addresses are in the range 2001:DB8::/32, you have a couple 2001:DB9::/32 addresses that should be changed I think. * There is still one instance of [0x4001] which can be replaced with (0x4001). * Replace the informative reference to RFC6555 with a reference to RFC8305. The rest of my comments are just a small number of follow-ups on other items that weren't fixed from my previous comments. * My earlier comment suggested added an explanation of why EVEN-PORT is not allowed with ADDITIONAL-ADDRESS-FAMILY to section 4. Your response was that this should not be moved to section 4. My primary point was that the related section (now 7.1) doesn't explain the reason for this restriction. Whether in section 4 or section 7.1, I do still think it would be good to state why EVEN-PORT MUST NOT be combined with ADDITIONAL-ADDRESS-FAMILY. * I'm still confused about the 5-tuple uniqueness requirement. The old text stated that "... the 5-tuple MUST be unique across all allocations, ..." In your response, you state "With the dual allocation, the 5-tuple no longer unqiuely identifies an allocation." and also "5-tuple will either identify a single or dual allocation." These two statements appear to contradict each other. I believe that a 5-tuple MUST be unique across all allocations, where an allocation in this context could be either a single or dual allocation. * Regarding this text in section 16.6: "The REQUESTED-ADDRESS-TYPE attribute MAY only be present in Allocate requests." Although this text was copied directly from RFC6156, it was already incorrect there (it's REQUESTED-ADDRESS-FAMILY and I think it intends "SHALL" or "MUST", not "MAY"). That said, this I-D changes the usage such that this attribute is now allowed in a Refresh request. Considering that the only usages for this attribute are clearly described above, I think it's OK to just remove the sentence altogether. Perhaps the first sentence in this section could be changed to further clarify: This attribute is used in Allocate and Refresh requests to specify the address type requested by the client. * Regarding this text in section 16.12: "The ADDRESS-ERROR-CODE attribute MAY only be present in Allocate responses." See my previous comment about "MAY" vs "SHALL"/"MUST". I still don't think this normative text is required in an attribute description. Most of the others don't have it. Pleae let me know if you have any questions about the above, and also when you will be able to target addressing the remaining open items. Thanks, --Brandon On 02/09/2018 02:44 AM, Konda, Tirumaleswar Reddy wrote: > Hi Brandon, > > Thanks for the detailed review. I have updated the draft to address most of the comments, please see the attached doc for responses to some of comments and nits. > > Cheers, > -Tiru > >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Sent: Sunday, November 12, 2017 11:34 PM >> To: Konda, Tirumaleswar Reddy >> ; tram@ietf.org >> Cc: draft-ietf-tram-turnbis@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt >> >> Hi Tiru, >> >> I just finished a comprehensive review of the cumulative diffs against >> RFC5766. See attached (let me know if you prefer me to resend as e-mail >> body for list purposes). >> >> You indicate that you addressed Marc's dual allocation related comments, >> but this draft doesn't address his comprehensive review comments, right? >> >> Please let me know a target for addressing the rest of his comments and >> mine so I can try to stay on top of the shepherding work for the draft. >> >> Thanks, >> --Brandon >> ________________________________________ >> From: Konda, Tirumaleswar Reddy >> >> Sent: Monday, October 23, 2017 2:48 AM >> To: tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt >> >> This revision addresses comments from Brandon and dual allocation related >> comments from Mark. >> >> -Tiru >> >>> -----Original Message----- >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- >>> drafts@ietf.org >>> Sent: Monday, October 23, 2017 12:14 PM >>> To: i-d-announce@ietf.org >>> Cc: tram@ietf.org >>> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the TURN Revised and Modernized WG of the >>> IETF. >>> >>> Title : Traversal Using Relays around NAT (TURN): Relay Extensions >>> to Session Traversal Utilities for NAT (STUN) >>> Authors : Tirumaleswar Reddy >>> Alan Johnston >>> Philip Matthews >>> Jonathan Rosenberg >>> Filename : draft-ietf-tram-turnbis-12.txt >>> Pages : 83 >>> Date : 2017-10-22 >>> >>> Abstract: >>> If a host is located behind a NAT, then in certain situations it can >>> be impossible for that host to communicate directly with other hosts >>> (peers). In these situations, it is necessary for the host to use >>> the services of an intermediate node that acts as a communication >>> relay. This specification defines a protocol, called TURN (Traversal >>> Using Relays around NAT), that allows the host to control the >>> operation of the relay and to exchange packets with its peers using >>> the relay. TURN differs from some other relay control protocols in >>> that it allows a client to communicate with multiple peers using a >>> single relay address. >>> >>> The TURN protocol was designed to be used as part of the ICE >>> (Interactive Connectivity Establishment) approach to NAT traversal, >>> though it also can be used without ICE. >>> >>> This document obsoletes [RFC5766] and [RFC6156]. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-tram-turnbis-12 >>> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-12 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-12 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> -- >> Brandon Williams; Chief Architect >> Cloud Networking; Akamai Technologies Inc. >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram From nobody Thu Feb 22 06:37:54 2018 Return-Path: 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 61B2C12711E; Thu, 22 Feb 2018 06:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 t-80D24LloBH; Thu, 22 Feb 2018 06:37:50 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5B41270A3; Thu, 22 Feb 2018 06:37:49 -0800 (PST) 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=1519310262; h=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-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=g 9VGHYgXdjiBGIYAtWwHEh+ISvk7QpwUXGvaBvyxi2 M=; b=RLbU58++Tg2n9C67PEjY9tTzwbXiu69z8lEpgn3Cc1OO hWX826lNKCjgBxJPCdmEhDDj3KY1Ps+05b+Ei5y96yPdfWYwiF 0gqcbkdNZQ0k8Geuxfo2ylUSHmlop47XnMQN4IqeJx2dI9nXPd didzjIG2qjz2boxgoWtGB8GoeAE= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 677d_63e5_8190c900_bec2_4671_9636_9f3cd34dc5de; Thu, 22 Feb 2018 08:37:41 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 22 Feb 2018 07:37:40 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 22 Feb 2018 07:37:40 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 22 Feb 2018 07:36:47 -0700 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1619.namprd16.prod.outlook.com (10.172.27.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Thu, 22 Feb 2018 14:37:38 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([10.172.207.19]) by BN6PR16MB1425.namprd16.prod.outlook.com ([10.172.207.19]) with mapi id 15.20.0527.017; Thu, 22 Feb 2018 14:37:38 +0000 From: "Konda, Tirumaleswar Reddy" To: Brandon Williams , "tram@ietf.org" CC: "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: Review of draft-ietf-tram-turnbis-13.txt (was Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt) Thread-Index: AQHTq1GmEd8Qx8iKkk+jFYAOL3R5xKOwOfHg Date: Thu, 22 Feb 2018 14:37:38 +0000 Message-ID: References: <150874106330.24567.10025213746592540332@ietfa.amsl.com> <61866009-27d0-bdce-815f-7905d69cd661@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [171.61.123.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1619; 7:z1mqj9wJjI5O3QM5wsr5SxKNWEqu2YxYS0wc1nxmXaeLwe8FWjTt82nat0Jwxm5d772yWQi2Z+rFQ4S+ncgibqrhgzoVSRyttG2pw2tAk2ouJV5OBvjLceYbxJG1l7/WLpObRUEBvDiUNhxwjJNMq7f6eCZiPeNZvuoNjQ+Y+5bM3r4rAhuC0rW6uBgA/0C9PiR2Kd1H9TwDwAm6XiqBP5WFkh1cplvN1XF/gODe1R3R7eaPDpXv9H/CFhLmMibG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6b40dd32-30a4-4027-4ba1-08d57a01d270 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN6PR16MB1619; x-ms-traffictypediagnostic: BN6PR16MB1619: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(788757137089)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001080)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(944501161)(10201501046)(93006095)(93001095)(6041288)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR16MB1619; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1619; x-forefront-prvs: 059185FE08 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39380400002)(39850400004)(396003)(32952001)(13464003)(377424004)(199004)(189003)(51914003)(52314003)(74316002)(99286004)(7736002)(305945005)(76176011)(7696005)(105586002)(66066001)(86362001)(33656002)(106356001)(4326008)(14454004)(72206003)(53936002)(478600001)(110136005)(81166006)(8676002)(8936002)(59450400001)(81156014)(5660300001)(53546011)(6506007)(68736007)(25786009)(316002)(186003)(77096007)(26005)(102836004)(80792005)(3660700001)(4001150100001)(5890100001)(2501003)(3846002)(93886005)(6116002)(97736004)(3280700002)(55016002)(2900100001)(2950100002)(6436002)(966005)(2906002)(9686003)(6306002)(6246003)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1619; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: irj6LdA2ndAHBY2LVLH2pRIsI1hbijFSSB2rKGbB2Gk3JTx+wF8vGrKcyyBA7+fsUxY97a2Xe/vXQnUL3VQfRLrfPtZNQFGfl+d5TClmZoRyT4CEkLHAynzTmkX6Rs8n6Bbwi7+/2yye5bHhvslDqCv/ulxBmGlnphc3nqpN8Vc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6b40dd32-30a4-4027-4ba1-08d57a01d270 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2018 14:37:38.5048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1619 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6228> : inlines <6424> : streams <1779723> : uri <2597423> Archived-At: Subject: Re: [tram] Review of draft-ietf-tram-turnbis-13.txt (was Re: I-D Action: draft-ietf-tram-turnbis-12.txt) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 14:37:52 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Thursday, February 22, 2018 1:51 AM > To: Konda, Tirumaleswar Reddy > ; tram@ietf.org > Cc: draft-ietf-tram-turnbis@ietf.org > Subject: Review of draft-ietf-tram-turnbis-13.txt (was Re: [tram] I-D Act= ion: > draft-ietf-tram-turnbis-12.txt) >=20 > Hi Tiru, >=20 > Most of my comments have been addressed with this update. >=20 > There are still a few issues raised by idnits, two of which are errors. >=20 > =3D=3D start idnits =3D=3D=3D >=20 > Checking nits according to https://www.ietf.org/id-info/checklist : >=20 > -------------------------------------------------------------------------= --- >=20 > ** The abstract seems to contain references ([RFC6156], [RFC5766]), > which it shouldn't. Please replace those with straight textual > mentions of the documents in question. >=20 > -- The document has examples using IPv4 documentation addresses > according to RFC6890, but does not use any IPv6 documentation > addresses. Maybe there should be IPv6 examples, too? >=20 > -- The draft header indicates that this document obsoletes RFC6156, > but th abstract doesn't seem to directly say this. It does mention > RFC6156 though, so this could be OK. >=20 > Checking references for intended status: Proposed Standard >=20 > -------------------------------------------------------------------------= --- >=20 > (See RFCs 3967 and 4897 for information about using normative > references to lower-maturity documents in RFCs) >=20 > =3D=3D Missing Reference: '0x4001' is mentioned on line 662, but not > defined >=20 > ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) >=20 > =3D=3D end idnits =3D=3D=3D >=20 > Based on the above. >=20 > * The RFC mentions in the abstract should not be links. Please remove > the xref tags and replace with simple textual references. From the > look of stunbis, which doesn't use xref tags, the HTML doc system > appears to turn them into hyperlinks anyway, which is weird. > Nevertheless, doing it the way you did generates an error from idnits > and errors should really be corrected. Fixed.=20 >=20 > * I think the point about IPv6 documentation addresses is just because > something about the formatting is causing it not to matching against > the small number of them in section 19.4. That said, IPv6 > documentation addresses are in the range 2001:DB8::/32, you have a > couple 2001:DB9::/32 addresses that should be changed I think. Updated 2001:DB9::1 to 2001:DB8:1::1 >=20 > * There is still one instance of [0x4001] which can be replaced with > (0x4001). Fixed.=20 >=20 > * Replace the informative reference to RFC6555 with a reference to > RFC8305. Done.=20 >=20 > The rest of my comments are just a small number of follow-ups on other > items that weren't fixed from my previous comments. >=20 > * My earlier comment suggested added an explanation of why EVEN-PORT is > not allowed with ADDITIONAL-ADDRESS-FAMILY to section 4. Your > response > was that this should not be moved to section 4. My primary point was > that the related section (now 7.1) doesn't explain the reason for this > restriction. Whether in section 4 or section 7.1, I do still think it > would be good to state why EVEN-PORT MUST NOT be combined with > ADDITIONAL-ADDRESS-FAMILY. If EVEN-PORT with R bit set to 1 is allowed, the handling of RESERVATION-TO= KEN needs to be changed (two tokens have to=20 be returned in the success response).=20 >=20 > * I'm still confused about the 5-tuple uniqueness requirement. The old > text stated that "... the 5-tuple MUST be unique across all > allocations, ..." In your response, you state "With the dual > allocation, the 5-tuple no longer unqiuely identifies an allocation." > and also "5-tuple will either identify a single or dual allocation." > These two statements appear to contradict each other. I believe that a > 5-tuple MUST be unique across all allocations, where an allocation in > this context could be either a single or dual allocation. Agreed, updated text. NEW: Both the relayed transport address and the 5-tuple MUST be unique across al= l allocations, so either one can be used to uniquely identify the allocatio= n,=20 and an allocation in this context can either be a single or dual allocation= . >=20 > * Regarding this text in section 16.6: "The REQUESTED-ADDRESS-TYPE > attribute MAY only be present in Allocate requests." Although this > text was copied directly from RFC6156, it was already incorrect there > (it's REQUESTED-ADDRESS-FAMILY and I think it intends "SHALL" or > "MUST", not "MAY"). That said, this I-D changes the usage such that > this attribute is now allowed in a Refresh request. Considering that > the only usages for this attribute are clearly described above, I > think it's OK to just remove the sentence altogether.=20 Agreed, removed line. > Perhaps the > first sentence in this section could be changed to further clarify: >=20 > This attribute is used in Allocate and Refresh requests to specify > the address type requested by the client. Updated the first line. >=20 > * Regarding this text in section 16.12: "The ADDRESS-ERROR-CODE > attribute MAY only be present in Allocate responses." See my previous > comment about "MAY" vs "SHALL"/"MUST". I still don't think this > normative text is required in an attribute description. Most of the > others don't have it. Removed line. Cheers, -Tiru >=20 >=20 > Pleae let me know if you have any questions about the above, and also whe= n > you will be able to target addressing the remaining open items. >=20 > Thanks, > --Brandon >=20 > On 02/09/2018 02:44 AM, Konda, Tirumaleswar Reddy wrote: > > Hi Brandon, > > > > Thanks for the detailed review. I have updated the draft to address mos= t of > the comments, please see the attached doc for responses to some of > comments and nits. > > > > Cheers, > > -Tiru > > > >> -----Original Message----- > >> From: Brandon Williams [mailto:brandon.williams@akamai.com] > >> Sent: Sunday, November 12, 2017 11:34 PM > >> To: Konda, Tirumaleswar Reddy > >> ; tram@ietf.org > >> Cc: draft-ietf-tram-turnbis@ietf.org > >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt > >> > >> Hi Tiru, > >> > >> I just finished a comprehensive review of the cumulative diffs > >> against RFC5766. See attached (let me know if you prefer me to resend > >> as e-mail body for list purposes). > >> > >> You indicate that you addressed Marc's dual allocation related > >> comments, but this draft doesn't address his comprehensive review > comments, right? > >> > >> Please let me know a target for addressing the rest of his comments > >> and mine so I can try to stay on top of the shepherding work for the d= raft. > >> > >> Thanks, > >> --Brandon > >> ________________________________________ > >> From: Konda, Tirumaleswar Reddy > >> > >> Sent: Monday, October 23, 2017 2:48 AM > >> To: tram@ietf.org > >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt > >> > >> This revision addresses comments from Brandon and dual allocation > >> related comments from Mark. > >> > >> -Tiru > >> > >>> -----Original Message----- > >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > >>> drafts@ietf.org > >>> Sent: Monday, October 23, 2017 12:14 PM > >>> To: i-d-announce@ietf.org > >>> Cc: tram@ietf.org > >>> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the TURN Revised and Modernized WG of > >>> the IETF. > >>> > >>> Title : Traversal Using Relays around NAT (TURN): = Relay > Extensions > >>> to Session Traversal Utilities for NAT (STUN) > >>> Authors : Tirumaleswar Reddy > >>> Alan Johnston > >>> Philip Matthews > >>> Jonathan Rosenberg > >>> Filename : draft-ietf-tram-turnbis-12.txt > >>> Pages : 83 > >>> Date : 2017-10-22 > >>> > >>> Abstract: > >>> If a host is located behind a NAT, then in certain situations it = can > >>> be impossible for that host to communicate directly with other ho= sts > >>> (peers). In these situations, it is necessary for the host to us= e > >>> the services of an intermediate node that acts as a communication > >>> relay. This specification defines a protocol, called TURN (Trave= rsal > >>> Using Relays around NAT), that allows the host to control the > >>> operation of the relay and to exchange packets with its peers usi= ng > >>> the relay. TURN differs from some other relay control protocols = in > >>> that it allows a client to communicate with multiple peers using = a > >>> single relay address. > >>> > >>> The TURN protocol was designed to be used as part of the ICE > >>> (Interactive Connectivity Establishment) approach to NAT traversa= l, > >>> though it also can be used without ICE. > >>> > >>> This document obsoletes [RFC5766] and [RFC6156]. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > >>> > >>> There are also htmlized versions available at: > >>> https://tools.ietf.org/html/draft-ietf-tram-turnbis-12 > >>> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-12 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-12 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission until the htmlized version and diff are available at > tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> tram mailing list > >>> tram@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tram > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram > >> > >> > >> -- > >> Brandon Williams; Chief Architect > >> Cloud Networking; Akamai Technologies Inc. > >> > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram From nobody Fri Feb 23 02:01:47 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 187A21242EA; Fri, 23 Feb 2018 02:01:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151938010105.22640.16447250160507291406@ietfa.amsl.com> Date: Fri, 23 Feb 2018 02:01:41 -0800 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-turnbis-14.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 10:01:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized WG of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-14.txt Pages : 83 Date : 2018-02-23 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. This document obsoletes RFC 5766 and RFC 6156. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-turnbis-14 https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 23 02:03:51 2018 Return-Path: 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 1CC92126BF0 for ; Fri, 23 Feb 2018 02:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 2JKAgfzcAEmx for ; Fri, 23 Feb 2018 02:03:47 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E041242EA for ; Fri, 23 Feb 2018 02:03:46 -0800 (PST) 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=1519380226; h=From: To: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:x-originating-ip: x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: x-microsoft-antispam-message-info:spamdiagnosticoutput: spamdiagnosticmetadata: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=S 0to87RNxhd68j8IHY7uV6TyQoHR93fJzFKzWErumd E=; b=c5YTIORFWEw167p921JRpMIASh2lL3HvQ89fiheD0bFR XsVCROffznR9BLNj+Ma1QDJlZPKhN1O9zXs0zhzg7mfQNLZQv5 yzVedgs1kvTC8y6Ki0DXjeG3jBth1aK3fj3xjkz8oeVP5AMaki Yzc0QgGjKDif+sM5r/BPgut7KzU= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2b25_2934_b06e895d_b1a5_4db2_93f6_413255862298; Fri, 23 Feb 2018 04:03:45 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 23 Feb 2018 03:03:45 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 23 Feb 2018 03:03:44 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 23 Feb 2018 03:03:44 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 23 Feb 2018 03:03:42 -0700 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1652.namprd16.prod.outlook.com (10.172.27.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Fri, 23 Feb 2018 10:03:42 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([10.172.207.19]) by BN6PR16MB1425.namprd16.prod.outlook.com ([10.172.207.19]) with mapi id 15.20.0527.017; Fri, 23 Feb 2018 10:03:42 +0000 From: "Konda, Tirumaleswar Reddy" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-14.txt Thread-Index: AQHTrI1s+OrfpVpYNkmxAemHa7Vti6Oxwf4w Date: Fri, 23 Feb 2018 10:03:42 +0000 Message-ID: References: <151938010105.22640.16447250160507291406@ietfa.amsl.com> In-Reply-To: <151938010105.22640.16447250160507291406@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1652; 7:e0xi+gTnCxiNZxzMQ/hLICI7W7+KStpP4tqPRPc0ky9s52hOGFWXqQS5rtZMD+9m7eVcLFMxYAvdrLq/nWou+8bXfPlOyigW6+MepV9CCGsL17BLDV/rq3oNd9MRkH+IxKAtQvpAUkZcOxk/iHQcOq51HsL27bunt7O5asPMYJr+TH+Kt9vWknySGTeOBnTRDq9dH8FVCGjS4CbDPkd03UR892SHsSTzErN+6x570X/+0HzGiMZ1mBwWT/0F8iH1 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 755f4e15-9ddf-4cd8-454a-08d57aa4b836 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN6PR16MB1652; x-ms-traffictypediagnostic: BN6PR16MB1652: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(3231183)(944501161)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041288)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR16MB1652; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1652; x-forefront-prvs: 0592A9FDE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(39380400002)(366004)(376002)(189003)(199004)(377424004)(32952001)(13464003)(478600001)(6346003)(66066001)(99286004)(3846002)(3660700001)(6306002)(97736004)(6916009)(77096007)(9686003)(2950100002)(72206003)(316002)(26005)(55016002)(6436002)(53936002)(76176011)(186003)(7696005)(68736007)(966005)(106356001)(33656002)(6116002)(8676002)(81156014)(81166006)(1730700003)(25786009)(8936002)(86362001)(3280700002)(105586002)(2351001)(53546011)(6506007)(2501003)(102836004)(14454004)(2900100001)(74316002)(5640700003)(80792005)(5660300001)(6246003)(7736002)(305945005)(229853002)(2906002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1652; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-message-info: mfZoTOEY0fVAyM3F7ga6xD2MqoyaEQLZDn1MXKMYvtBoWsOo1HOsgULCCC8Olmqk8R7jgGVG2YSyhll3n+OmQfy3Dtwchejlm4PrKW9g00safxH7dnXp5o1yetC2ys1AHZ5PMuN0OFoEQa9tHbxO3T3D9forGasY92WsY95Puo8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 755f4e15-9ddf-4cd8-454a-08d57aa4b836 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2018 10:03:42.5020 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1652 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6228> : inlines <6429> : streams <1779800> : uri <2597898> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-14.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 10:03:49 -0000 This revision addresses comments from Brandon. Cheers, -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, February 23, 2018 3:32 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-14.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized WG of the > IETF. >=20 > Title : Traversal Using Relays around NAT (TURN): Relay= Extensions > to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-14.txt > Pages : 83 > Date : 2018-02-23 >=20 > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. >=20 > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. >=20 > This document obsoletes RFC 5766 and RFC 6156. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tram-turnbis-14 > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-14 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Feb 23 14:37:55 2018 Return-Path: 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 68E1C126C22; Fri, 23 Feb 2018 14:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HaN5Ss5juwyA; Fri, 23 Feb 2018 14:37:37 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506D6126BF7; Fri, 23 Feb 2018 14:37:34 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id w12so3325270ywa.8; Fri, 23 Feb 2018 14:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+lOx/JnRaIDlYvMUpzVO7TfASXeONyPidhi6i84Kw8w=; b=gDfd3s6RihiTL4QF7nks948Ex2i36EDEPd+Kjn9MxGUUp+RWnIvi8UZaJeGkhBSn0d RRdVyV2GyS2lACBUBq1CCmoEDljcsjVDh00c/nqidLkpqgFFprXRSQXOBccKoT6/UJRE GD85FmxQh3trEr4EvWmng9E26gu19Cf2GKoDpXJjqzS6gALFxUyVYOU069tYlAoQujSg Ett8e30oCoOXSKFL7hd3P4syEP0dKiD+59j6eu8DTZGc0x7YzylWnzstNdb8dInGrVoi RjBcR2b45cBkOMuaiseaxGw+m3lNt2Uis5mK57gBYpwxO3oPAM+sKhCm3yphLE2DvvfX NLGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+lOx/JnRaIDlYvMUpzVO7TfASXeONyPidhi6i84Kw8w=; b=J+zMOXT1J4Tbz2wlmVYEJ+Vd/r5EftkbA8yTz/c3Iw/kqyLwjy6RkDvxuAP+e+JA4l /oZy+B63nAxH6GCggbXLZNQclHEa3z+2wiwINZ1SzmTw2NnQnzlDl6nPiGPEmME6KIPl kFDjcAj8sNBcviJYJrrkGDbJ1IJ8joQkVlmQ8CimADGi70qPTfwl7W8ide6w1l8RgM8x hXQjeoY09FSqIebPWDkbxFuoJA4i9jr9r4YAijY/X0tjbduvmJNPZ9Us3GZyZ65cG6E4 nQ3y+KPjV7rG9I3VcptBdvSajuqpx8xauoC3FYd2kvmC01f84bhxI9ToeKMob0F02dVg UA2A== X-Gm-Message-State: APf1xPBDRE1P49vYbPdimo2u9JYc4VR5AKUsUsQqlf3LtEHmqZkfhoTj uhbaUBagIl/OnXknix/5QuvpvD78F6ELqAPlP/c= X-Google-Smtp-Source: AH8x227JWXuWESSptKcLVDXooiiWLEfUwoB912yRC+fxrtYNeZA6t0yAaVPGQ4uORSeqoZ7bRuL1nmh6eEjsh6PtDY0= X-Received: by 10.129.102.196 with SMTP id a187mr2309785ywc.19.1519425452797; Fri, 23 Feb 2018 14:37:32 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:15c9:0:0:0:0:0 with HTTP; Fri, 23 Feb 2018 14:37:32 -0800 (PST) In-Reply-To: <151906144357.18629.1445621426796368031@ietfa.amsl.com> References: <151906144357.18629.1445621426796368031@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 23 Feb 2018 16:37:32 -0600 Message-ID: To: draft-ietf-tram-stunbis.all@ietf.org Cc: gen-art , IETF list , tram@ietf.org, Dale Worley Content-Type: multipart/alternative; boundary="001a11470a2660759c0565e8ce57" Archived-At: Subject: Re: [tram] Genart last call review of draft-ietf-tram-stunbis-15 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 22:37:44 -0000 --001a11470a2660759c0565e8ce57 Content-Type: text/plain; charset="UTF-8" Dear Authors, Now that Last Call for this draft has ended, could you folks take a look at Dale's comments and respond? Thanks! Spencer, as responsible AD On Mon, Feb 19, 2018 at 11:30 AM, Dale Worley wrote: > Reviewer: Dale Worley > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > Document: draft-ietf-tram-stunbis-15 > Reviewer: Dale R. Worley > Review Date: 2018-02-19 > IETF LC End Date: 2018-02-20 > IESG Telechat date: [unknown] > > Summary: > > This draft is on the right track but has open issues, described > in the review. > > Overall, the draft is quite well organized and well written. But > there are a number of open issues that have substantial technical > content. I suspect that the intended design does not have these > issues, and the issues that I see are just where the text hasn't been > fully updated to match the intended design. > > Dale > > ---------------------------------------------------------------------- > > There is an issue that shows up in several places: The NAT may > forward the request using an IP family that is different from the IP > family that it received the request using. This means that the > "source IP family of the request" may depend on whether one is > speaking of the client or the server. The draft is cognizant of this, > and mentions its consequences in sections 6.3.3 and 12. But this also > has consequences for ALTERNATE-SERVER: Section 14.15 says "The IP > address family MUST be identical to that of the source IP address of > the request." even though that family might not be usable by the > client. The draft doesn't seem to explicitly say that this comes from > address-switching by the NAT. It would help if there was a > higher-level discussion of this matter, pointing to the various > consequences. > > The text contains these references to SHA algorithms (that it does not > itself define). Some should be corrected: > > HMAC-SHA1 > HMAC-SHA-1 > should be HMAC-SHA1 per RFC 2104 > HMAC-SHA256 > HMAC-SHA-256 > should be HMAC-SHA256 per RFC 6151, but HMAC-SHA-256 per RFC 6151! > SHA1 > SHA-1 > It appears that the proper name of this function is SHA-1. > SHA256 > SHA-256 > NIST calls this algorithm SHA-256. > > 3. Terminology > > This section needs to be updated to reference RFC 8174. > > 4. Definitions > > Although the definitions of STUN Client and STUN Server mention that > they receive responses and requests (respectively), they don't mention > that they also receive indications. > > 5. STUN Message Structure > > All STUN messages MUST start with a 20-byte header followed by zero > or more Attributes. > > It would be clearer, I think, to say "All STUN messages comprise a > 20-byte header followed by zero or more Attributes." > > 6.2.2. Sending over TCP or TLS-over-TCP > > The client MAY send multiple transactions over a single TCP (or TLS- > over-TCP) connection, and it MAY send another request before > receiving a response to the previous. > > s/the previous./the previous request./ > > This section should also state whether or not a server is allowed to > provide responses in a different order than it received the requests, > if it receives further requests before sending a response. > > o if multiplexing other application protocols over that port, has > finished using that other application, and > > s/that other application/that other protocol/ > > 6.3.4. Processing an Error Response > > o If the error code is 300 through 399, the client SHOULD consider > the transaction as failed unless the ALTERNATE-SERVER extension is > being used. See Section 10. > > This syntax binds "section 10" to the entire preceding sentence, whose > topic is error codes 300-399, whereas "section 10" only applies to > ALTERNATE-SERVER. A better syntax would be > > o If the error code is 300 through 399, the client SHOULD consider > the transaction as failed unless the ALTERNATE-SERVER extension > (Section 10) is being used. > > 9.2. Long-Term Credential Mechanism > > Note that the long-term credential mechanism cannot be used to > protect indications, since indications cannot be challenged. Usages > utilizing indications must either use a short-term credential or omit > authentication and message integrity for them. > > Alternatively, if there has been a recent request transaction between > the client and the server, then a nonce have been established, and an > indication can be sent securely using the long-term mechanism. > (Although there is no mechanism for signaling if the nonce has become > stale.) It seems to me plausible that some usage may wish to exploit > this possibility. > > 9.2.1. Bid Down Attack Prevention > > To indicate that it supports this specification, a server MUST > prepend the NONCE attribute value with the character string composed > of "obMatJos2" concatenated with the Base64 [RFC4648] encoding of the > 24 bit STUN Security Features as defined in Section 17.1. > > It might be informative to note that the encoding of the security > features is always four characters long: > s/the Base64 [RFC4648] encoding/the (4 character) Base64 [RFC4648] > encoding/ > > 9.2.2. HMAC Key > > The structure of the key when used with long-term credentials > facilitates deployment in systems that also utilize SIP. Typically, > SIP systems utilizing SIP's digest authentication mechanism do not > actually store the password in the database. > > Presumably there should be an explicit reference [RFC3261] here. > > 9.2.3. Forming a Request > > This section defines "first request from the client to the server" as > being "identified by its IP address and port". However in section > 9.2.3.1, "the server" is "identified by hostname, if the DNS > procedures of Section 8 are used, else IP address if not". These are > not the same, and presumably need to be aligned on the correct > definition. (And perhaps one section can simply refer to the > definition in the other section.) Alternatively, they may be intended > to be different, in which case the text needs to be clarified and also > warn the reader. > > 9.2.3.1. First Request > > In other words, the very first request is sent [...] > > It seems better style to omit "very", given that "first request" has a > specific meaning. > > 9.2.4. Receiving a Request > > The > server MUST ensure that the same NONCE cannot be selected for > clients that use different source IP addresses, different source > ports, or both different source IP addresses and source ports. > > It seems clearer to phrase this condition "The server MUST NOT choose > the same NONCE for two requests unless they have the same source IP > address and port." > > o If the NONCE attribute starts with the "nonce cookie" with the > STUN Security Feature "Password algorithm" bit set to 1 but > PASSWORD-ALGORITHMS does not match the value sent in the response > that sent this NONCE, then the server MUST generate an error > response with an error code of 400 (Bad Request). > > o If the NONCE attribute starts with the "nonce cookie" with the > STUN Security Feature "Password algorithm" bit set to 1 but the > request contains neither PASSWORD-ALGORITHMS nor PASSWORD- > ALGORITHM, then the request is processed as though PASSWORD- > ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS > attribute did not contain MD5, this will result in a 400 Bad > Request in a later step below). > > o If the NONCE attribute starts with the "nonce cookie" with the > STUN Security Feature "Password algorithm" bit set to 1 but only > one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then > the server MUST generate an error response with an error code of > 400 (Bad Request). > > o If the NONCE attribute starts with the "nonce cookie" with the > STUN Security Feature "Password algorithm" bit set to 1 but > PASSWORD-ALGORITHM does not match one of the entries in PASSWORD- > ALGORITHMS, then the server MUST generate an error response with > an error code of 400 (Bad Request). > > Given these cases all include one long condition, it seems like it > would be clearer if they were grouped and the condition factored out: > > o If the NONCE attribute starts with the "nonce cookie" with the > STUN Security Feature "Password algorithm" bit set to 1, the > server performs these checks in the order specified: > > * If PASSWORD-ALGORITHMS does not match the value sent in the > response > that sent this NONCE, then the server MUST generate an error > response with an error code of 400 (Bad Request). > > * If the request contains neither PASSWORD-ALGORITHMS nor PASSWORD- > ALGORITHM, then the request is processed as though PASSWORD- > ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS > attribute did not contain MD5, this will result in a 400 Bad > Request in a later step below). > > * If > only one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, > then > the server MUST generate an error response with an error code of > 400 (Bad Request). > > * If PASSWORD-ALGORITHM does not match one of the entries in > PASSWORD- > ALGORITHMS, then the server MUST generate an error response with > an error code of 400 (Bad Request). > > This could be further shortened and clarified by using the negation of > the condition we desire: > > o If the NONCE attribute starts with the "nonce cookie" with the > STUN Security Feature "Password algorithm" bit set to 1, the > server performs these checks in the order specified: > > * If the request contains neither PASSWORD-ALGORITHMS nor PASSWORD- > ALGORITHM, then the request is processed as though PASSWORD- > ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS > attribute did not contain MD5, this will result in a 400 Bad > Request in a later step below). > > * Otherwise, unless (1) PASSWORD-ALGORITHM and > PASSWORD-ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS > matches the value sent in the response that sent this NONCE, > and (3) PASSWORD-ALGORITHM matches one of the entries in > PASSWORD-ALGORITHMS, the server MUST generate an error > response with an error code of 400 (Bad Request). > > -- > > Servers can > invalidate nonces in order to provide additional security. > > It's not clear what "invalidate" means here. The text has been > talking about nonces expiring, which suggests that it is not a process > that the server actively causes at the time the nonce becomes invalid, > but "invalidate" suggests that the server causes it at the moment of > invalidation. > > See Section 4.3 of [RFC7616] for guidelines. > > There is no section 4.3 in RFC 7616. > > 9.2.5. Receiving a Response > > If the test succeeds and the "nonce cookie" has > the STUN Security Feature "Username anonymity" bit set to 1 but no > USERHASH attribute is present, then the client MUST NOT retry the > request with a new transaction. > > I can find no reference to the server sending USERHASH in a response, > so I don't understand what this means. I think what was intended is > "... is set to 1, then the client MUST NOT retry the request using the > USERHASH attribute." But that requirement seems to be stated in the > next paragraph: > > If the response is an error response with an error code of 401 > (Unauthenticated), the client SHOULD retry the request with a new > transaction. [...] > If the "nonce cookie" was present and had > the STUN Security Feature "Username anonymity" bit set to 1 then the > USERHASH attribute MUST be used, else the USERNAME attribute MUST be > used. > > -- > > For all other responses, if the NONCE attribute > starts with the "nonce cookie" with the STUN Security Feature "User > anonymity" bit set to 1 but USERHASH is not present, the response > MUST be ignored. > > As above. > > The above texts suggest that there is, or was, an intention that the > server would reflect back the USERHASH value in responses. But > checking all the mentions of "USERHASH", I can find no text saying > that USERHASH will ever appear in responses. This design decision > needs to be verified and the text updated correspondingly. > > If the response is an error response with an error code of 400, and > does not contains either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- > SHA256 attribute then the response MUST be discarded, as if it was > never received. This means that retransmits, if applicable, will > continue. > > Some responses generated according to this specification will not pass > the above check. E.g., from section 9.2.4 item 2: > > o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- > INTEGRITY-SHA256 attribute, but is missing either the USERNAME or > USERHASH, REALM, or NONCE attribute, the server MUST generate an > error response with an error code of 400 (Bad Request). This > response SHOULD NOT include a USERNAME, USERHASH, NONCE, or REALM. > The response cannot contain a MESSAGE-INTEGRITY or MESSAGE- > INTEGRITY-SHA256 attribute, as the attributes required to generate > them are missing. > > How does the client effectively receive the error response in this > situation? > > 10. ALTERNATE-SERVER Mechanism > > To be clearer, the first paragraph should mention that the > ALTERNATE-SERVER attribute carries an IP address, not a domain name > (see section 14.15). In particular, that disambiguates the test for > "same server" in the last paragraph. > > The error response > message MAY be authenticated; however, there are uses cases for > ALTERNATE-SERVER where authentication of the response is not possible > or practical. > > s/uses cases/use cases/ > > If the client has been redirected to a > server on which it has already tried this request within the last > five minutes, [...] > > It is a little more formal to say "to a server to which it has already > sent this request ...". > > 11. Backwards Compatibility with RFC 3489 > > Any STUN request or indication > without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST > always result in an error. > > The meaning is clear, but in this document, "error" seems to be > limited to error responses. Perhaps better is: > > Any STUN request or indication > without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST > be considered invalid: requests MUST generate error responses and > indications MUST be ignored. > > Also, what error code should be used? > > 13. STUN Usages > > A usage would also define: > > I'm sure you don't want to use the subjunctive mood here, so perhaps > s/would/will/. OTOH, you might want to s/would/must/, or "A usage > also defines:" to parallel the first sentence of the paragraph. > > 14. STUN Attributes > > Note that there is an important ordering restriction on attributes: > the attributes MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256, and > FINGERPRINT must, if present, appear finally and in that order. There > also seems to be a rule that any attributes which follow one of these > attributes in violation of that rule MUST be ignored. > > This is described in those attribute definitions, but it's a global > constraint in the use of attributes, and I think should be pointed out > at this level of the specification. > > I'm nervous about the "must be ignored" rule, as it becomes a little > complicated to do the processing right in all cases. Perhaps it would > be better to declare that any such violation invalidates the message > instead? > > 14.3. USERNAME > > The value of USERNAME is a variable-length value. > > This doesn't actually say what the value is. Better: > > The value of USERNAME is a variable-length value containing the > authentication username. > > 14.5. MESSAGE-INTEGRITY > > Since it uses the SHA1 hash, the HMAC will be > at 20 bytes. > > I think "at" should be omitted. > > The text used as input to HMAC is the STUN message, including the > header, up to and including the attribute preceding the MESSAGE- > INTEGRITY attribute. With the exception of the MESSAGE-INTEGRITY- > SHA256 and FINGERPRINT attributes, which appear after MESSAGE- > INTEGRITY, agents MUST ignore all other attributes that follow > MESSAGE-INTEGRITY. > > This paragraph is troublesome. The matter of attribute ordering is > discussed above under section 14. But the description of calculating > the MAC disagrees with the description in the fourth paragraph. My > suspicion is that the fourth paragraph is correct. My choice would be > to omit this paragraph and leave its topics to be dealt with > elsewhere. > > Based on the rules above, the hash used to construct MESSAGE- > INTEGRITY includes the length field from the STUN message header. > Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be > inserted into the message (with dummy content). The length MUST then > be set to point to the length of the message up to, and including, > the MESSAGE-INTEGRITY attribute itself, but excluding any attributes > after it. Once the computation is performed, the value of the > MESSAGE-INTEGRITY attribute can be filled in, and the value of the > length in the STUN header can be set to its correct value -- the > length of the entire message. Similarly, when validating the > MESSAGE-INTEGRITY, the length field should be adjusted to point to > the end of the MESSAGE-INTEGRITY attribute prior to calculating the > HMAC. Such adjustment is necessary when attributes, such as > FINGERPRINT, appear after MESSAGE-INTEGRITY. > > I would rephrase this slightly, borrowing from the second paragraph: > > The text used as input to HMAC is the STUN message, up to and > including the MESSAGE-INTEGRITY attribute. The length field of the > STUN message header is adjusted to point to the end of the > MESSAGE-INTEGRITY attribute. The value of the MESSAGE-INTEGRITY > attribute is set to the dummy value ***. > > Once the computation is performed, the value of the > MESSAGE-INTEGRITY attribute is filled in, and the value of the > length in the STUN header is set to its correct value -- the > length of the entire message. Similarly, when validating the > MESSAGE-INTEGRITY, the length field must be adjusted to point to > the end of the MESSAGE-INTEGRITY attribute and the value of the > attribute set to *** prior to calculating the > HMAC. Such adjustment is necessary when attributes, such as > FINGERPRINT, appear after MESSAGE-INTEGRITY. > > Also, the text doesn't specify what the "dummy content" is! > > 14.6. MESSAGE-INTEGRITY-SHA256 > > This section has the same problems regarding the HMAC calculation as > section 14.5. > > The discussion of truncation seems to assume that the reader already > fully understands the concept. Better would be to explain it > explicitly, since that doesn't take more words: > > The MESSAGE-INTEGRITY-SHA256 attribute can be present in any STUN > message type. The MESSAGE-INTEGRITY-SHA256 attribute contains an > initial portion of the HMAC-SHA-256 [RFC2104] of the STUN message. > The value will be at most 32 bytes and MUST be a positive multiple > of 4 bytes. The value must be the full 32 bytes unless the STUN > usage explicitly specifies that truncation is allowed. Usages may > specify a minimum length longer than 4 bytes. > > 14.7. FINGERPRINT > > The FINGERPRINT attribute MAY be present in all STUN messages. The > value of the attribute is computed as the CRC-32 of the STUN message > up to (but excluding) the FINGERPRINT attribute itself, [...] > > Note that unlike the MESSAGE-INTEGRITY attributes, the FINGERPRINT > calculation does not prepare the text by adjusting the Length field of > the header. Verify that this is what is intended and perhaps mention > it explicitly. > > [...] up to (but excluding) the FINGERPRINT attribute itself, XOR'ed > with > the 32-bit value 0x5354554e (the XOR helps in cases where an > application packet is also using CRC-32 in it). > > This is awkward. Perhaps unpack it into: > > The value of the attribute is computed as the CRC-32 of the STUN > message up to (but excluding) the FINGERPRINT attribute itself, > XOR'ed with the 32-bit value 0x5354554e. (The XOR operation > ensures that the FINGERPRINT test will not report a false positive > on a packet containing a CRC-32 generated by an application > protocol.) > > 14.8. ERROR-CODE > > The Reserved bits SHOULD be 0, and are for alignment on 32-bit > boundaries. Receivers MUST ignore these bits. The Class represents > the hundreds digit of the error code. The value MUST be between 3 > and 6. The Number represents the error code modulo 100, and its > value MUST be between 0 and 99. > > How is Number encoded? I suspect that binary is intended, but it is > an 8-bit field holding a two-digit decimal number, and so might > plausibly be encoded as two nibbles containing the two digits. > > 14.9. REALM > > Presence in certain > error responses indicates that the server wishes the client to use a > long-term credential for authentication. > > I think you mean s/a long-term credential/a long-term credential in > that realm/. > > 14.10. NONCE > > Note that this means that the NONCE attribute will not contain > actual quote characters. > > More exactly, "will not contain the surrounding quote characters". > > But some thought should be given to using the same wording in 14.9 and > 14.10. > > 14.11. PASSWORD-ALGORITHMS > > The parameters start with the actual length of the > parameters as a 16-bit value, followed by the parameters that are > specific to each algorithm. > > "actual length" should be "length (prior to padding)". > > 14.12. PASSWORD-ALGORITHM > > The parameters starts with the actual length of the > parameters as a 16-bit value, followed by the parameters that are > specific to the algorithm. > > "actual length" should be "length (prior to padding)". > > 15.1.2. Inside Attacks > > Fortunately, STUN > requests can be processed statelessly by a server, making such > attacks hard to launch. > > Actually, such attacks are easy to launch, but "hard to launch > effectively". > > This attack is mitigated by ingress source address filtering. > > I would help to explain who is filtering and on what basis to > implement this mitigation. > > 15.2.4. Attack IV: Eavesdropping > > In this attack, the attacker forces the client to use a reflexive > address that routes to itself. > > "itself" usually refers to the subject of the verb in its clause, > which is "address". But I think "attacker" is intended, in which case > you can phrase it "that routes to the attacker itself". > > 17.1. STUN Security Features Registry > > New Security Features are assigned by a Standard Action [RFC8126]. > > s/Standard Action/Standards Action/ per RFC 8u126 section 4.9. > > 17.3.2. New Attributes > > 0xXXXX: PASSSORD-ALGORITHMS > > s/PASSSORD/PASSWORD/ > > 17.5. Password Algorithm Registry > > I think you want to title this registry "Stun password algorithm registry". > > 17.6. STUN UDP and TCP Port Numbers > > This section should state that it is updating "Service Name and > Transport Protocol Port Number Registry". > > 18. Changes since RFC 5389 > > The following items should contain proper references to the mentioned RFCs: > > o Added support for DTLS-over-UDP (RFC 6347). > > o Aligned the RTO calculation with RFC 6298. > > o Added support for STUN URI (RFC 7064). > > o Updated the PRECIS support to RFC 8265. > > [END] > > > --001a11470a2660759c0565e8ce57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors,

Now that Last Call for th= is draft has ended, could you folks take a look at Dale's comments and = respond?

Thanks!

Spencer,= as responsible AD

On Mon, Feb 19, 2018 at 11:30 AM, Dale Worley <worley@ariadne= .com> wrote:
Reviewer: Dale= Worley
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft.=C2=A0 The General Area Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

Document:=C2=A0 draft-ietf-tram-stunbis-15
Reviewer:=C2=A0 Dale R. Worley
Review Date:=C2=A0 2018-02-19
IETF LC End Date:=C2=A0 2018-02-20
IESG Telechat date:=C2=A0 [unknown]

Summary:

=C2=A0 =C2=A0 =C2=A0 =C2=A0This draft is on the right track but has open is= sues, described
=C2=A0 =C2=A0 =C2=A0 =C2=A0in the review.

Overall, the draft is quite well organized and well written.=C2=A0 But
there are a number of open issues that have substantial technical
content.=C2=A0 I suspect that the intended design does not have these
issues, and the issues that I see are just where the text hasn't been fully updated to match the intended design.

Dale

-----------------------------------------------------------------= -----

There is an issue that shows up in several places:=C2=A0 The NAT may
forward the request using an IP family that is different from the IP
family that it received the request using.=C2=A0 This means that the
"source IP family of the request" may depend on whether one is speaking of the client or the server.=C2=A0 The draft is cognizant of this,=
and mentions its consequences in sections 6.3.3 and 12.=C2=A0 But this also=
has consequences for ALTERNATE-SERVER:=C2=A0 Section 14.15 says "The I= P
address family MUST be identical to that of the source IP address of
the request." even though that family might not be usable by the
client.=C2=A0 The draft doesn't seem to explicitly say that this comes = from
address-switching by the NAT.=C2=A0 It would help if there was a
higher-level discussion of this matter, pointing to the various
consequences.

The text contains these references to SHA algorithms (that it does not
itself define).=C2=A0 Some should be corrected:

=C2=A0 =C2=A0 HMAC-SHA1
=C2=A0 =C2=A0 HMAC-SHA-1
should be HMAC-SHA1 per RFC 2104
=C2=A0 =C2=A0 HMAC-SHA256
=C2=A0 =C2=A0 HMAC-SHA-256
should be HMAC-SHA256 per RFC 6151, but HMAC-SHA-256 per RFC 6151!
=C2=A0 =C2=A0 SHA1
=C2=A0 =C2=A0 SHA-1
It appears that the proper name of this function is SHA-1.
=C2=A0 =C2=A0 SHA256
=C2=A0 =C2=A0 SHA-256
NIST calls this algorithm SHA-256.

3.=C2=A0 Terminology

This section needs to be updated to reference RFC 8174.

4.=C2=A0 Definitions

Although the definitions of STUN Client and STUN Server mention that
they receive responses and requests (respectively), they don't mention<= br> that they also receive indications.

5.=C2=A0 STUN Message Structure

=C2=A0 =C2=A0All STUN messages MUST start with a 20-byte header followed by= zero
=C2=A0 =C2=A0or more Attributes.

It would be clearer, I think, to say "All STUN messages comprise a
20-byte header followed by zero or more Attributes."

6.2.2.=C2=A0 Sending over TCP or TLS-over-TCP

=C2=A0 =C2=A0The client MAY send multiple transactions over a single TCP (o= r TLS-
=C2=A0 =C2=A0over-TCP) connection, and it MAY send another request before =C2=A0 =C2=A0receiving a response to the previous.

s/the previous./the previous request./

This section should also state whether or not a server is allowed to
provide responses in a different order than it received the requests,
if it receives further requests before sending a response.

=C2=A0 =C2=A0o=C2=A0 =C2=A0if multiplexing other application protocols over= that port, has
=C2=A0 =C2=A0 =C2=A0 =C2=A0finished using that other application, and

s/that other application/that other protocol/

6.3.4.=C2=A0 Processing an Error Response

=C2=A0 =C2=A0 o=C2=A0 If the error code is 300 through 399, the client SHOU= LD consider
=C2=A0 =C2=A0 =C2=A0 =C2=A0the transaction as failed unless the ALTERNATE-S= ERVER extension is
=C2=A0 =C2=A0 =C2=A0 =C2=A0being used.=C2=A0 See Section 10.

This syntax binds "section 10" to the entire preceding sentence, = whose
topic is error codes 300-399, whereas "section 10" only applies t= o
ALTERNATE-SERVER.=C2=A0 A better syntax would be

=C2=A0 =C2=A0 o=C2=A0 If the error code is 300 through 399, the client SHOU= LD consider
=C2=A0 =C2=A0 =C2=A0 =C2=A0the transaction as failed unless the ALTERNATE-S= ERVER extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0(Section 10) is being used.

9.2.=C2=A0 Long-Term Credential Mechanism

=C2=A0 =C2=A0Note that the long-term credential mechanism cannot be used to=
=C2=A0 =C2=A0protect indications, since indications cannot be challenged.= =C2=A0 Usages
=C2=A0 =C2=A0utilizing indications must either use a short-term credential = or omit
=C2=A0 =C2=A0authentication and message integrity for them.

Alternatively, if there has been a recent request transaction between
the client and the server, then a nonce have been established, and an
indication can be sent securely using the long-term mechanism.
(Although there is no mechanism for signaling if the nonce has become
stale.)=C2=A0 It seems to me plausible that some usage may wish to exploit<= br> this possibility.

9.2.1.=C2=A0 Bid Down Attack Prevention

=C2=A0 =C2=A0To indicate that it supports this specification, a server MUST=
=C2=A0 =C2=A0prepend the NONCE attribute value with the character string co= mposed
=C2=A0 =C2=A0of "obMatJos2" concatenated with the Base64 [RFC4648= ] encoding of the
=C2=A0 =C2=A024 bit STUN Security Features as defined in Section 17.1.

It might be informative to note that the encoding of the security
features is always four characters long:
s/the Base64 [RFC4648] encoding/the (4 character) Base64 [RFC4648] encoding= /

9.2.2.=C2=A0 HMAC Key

=C2=A0 =C2=A0The structure of the key when used with long-term credentials<= br> =C2=A0 =C2=A0facilitates deployment in systems that also utilize SIP.=C2=A0= Typically,
=C2=A0 =C2=A0SIP systems utilizing SIP's digest authentication mechanis= m do not
=C2=A0 =C2=A0actually store the password in the database.

Presumably there should be an explicit reference [RFC3261] here.

9.2.3.=C2=A0 Forming a Request

This section defines "first request from the client to the server"= ; as
being "identified by its IP address and port".=C2=A0 However in s= ection
9.2.3.1, "the server" is "identified by hostname, if the DNS=
procedures of Section 8 are used, else IP address if not".=C2=A0 These= are
not the same, and presumably need to be aligned on the correct
definition.=C2=A0 (And perhaps one section can simply refer to the
definition in the other section.)=C2=A0 Alternatively, they may be intended=
to be different, in which case the text needs to be clarified and also
warn the reader.

9.2.3.1.=C2=A0 First Request

=C2=A0 =C2=A0In other words, the very first request is sent [...]

It seems better style to omit "very", given that "first requ= est" has a
specific meaning.

9.2.4.=C2=A0 Receiving a Request

=C2=A0 =C2=A0 =C2=A0 The
=C2=A0 =C2=A0 =C2=A0 server MUST ensure that the same NONCE cannot be selec= ted for
=C2=A0 =C2=A0 =C2=A0 clients that use different source IP addresses, differ= ent source
=C2=A0 =C2=A0 =C2=A0 ports, or both different source IP addresses and sourc= e ports.

It seems clearer to phrase this condition "The server MUST NOT choose<= br> the same NONCE for two requests unless they have the same source IP
address and port."

=C2=A0 =C2=A0o=C2=A0 If the NONCE attribute starts with the "nonce coo= kie" with the
=C2=A0 =C2=A0 =C2=A0 STUN Security Feature "Password algorithm" b= it set to 1 but
=C2=A0 =C2=A0 =C2=A0 PASSWORD-ALGORITHMS does not match the value sent in t= he response
=C2=A0 =C2=A0 =C2=A0 that sent this NONCE, then the server MUST generate an= error
=C2=A0 =C2=A0 =C2=A0 response with an error code of 400 (Bad Request).

=C2=A0 =C2=A0o=C2=A0 If the NONCE attribute starts with the "nonce coo= kie" with the
=C2=A0 =C2=A0 =C2=A0 STUN Security Feature "Password algorithm" b= it set to 1 but the
=C2=A0 =C2=A0 =C2=A0 request contains neither PASSWORD-ALGORITHMS nor PASSW= ORD-
=C2=A0 =C2=A0 =C2=A0 ALGORITHM, then the request is processed as though PAS= SWORD-
=C2=A0 =C2=A0 =C2=A0 ALGORITHM were MD5 (Note that if the original PASSWORD= -ALGORITHMS
=C2=A0 =C2=A0 =C2=A0 attribute did not contain MD5, this will result in a 4= 00 Bad
=C2=A0 =C2=A0 =C2=A0 Request in a later step below).

=C2=A0 =C2=A0o=C2=A0 If the NONCE attribute starts with the "nonce coo= kie" with the
=C2=A0 =C2=A0 =C2=A0 STUN Security Feature "Password algorithm" b= it set to 1 but only
=C2=A0 =C2=A0 =C2=A0 one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is pr= esent, then
=C2=A0 =C2=A0 =C2=A0 the server MUST generate an error response with an err= or code of
=C2=A0 =C2=A0 =C2=A0 400 (Bad Request).

=C2=A0 =C2=A0o=C2=A0 If the NONCE attribute starts with the "nonce coo= kie" with the
=C2=A0 =C2=A0 =C2=A0 STUN Security Feature "Password algorithm" b= it set to 1 but
=C2=A0 =C2=A0 =C2=A0 PASSWORD-ALGORITHM does not match one of the entries i= n PASSWORD-
=C2=A0 =C2=A0 =C2=A0 ALGORITHMS, then the server MUST generate an error res= ponse with
=C2=A0 =C2=A0 =C2=A0 an error code of 400 (Bad Request).

Given these cases all include one long condition, it seems like it
would be clearer if they were grouped and the condition factored out:

=C2=A0 =C2=A0o=C2=A0 If the NONCE attribute starts with the "nonce coo= kie" with the
=C2=A0 =C2=A0 =C2=A0 STUN Security Feature "Password algorithm" b= it set to 1, the
=C2=A0 =C2=A0 =C2=A0 server performs these checks in the order specified:
=C2=A0 =C2=A0 =C2=A0 *=C2=A0 If PASSWORD-ALGORITHMS does not match the valu= e sent in the response
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that sent this NONCE, then the server MUS= T generate an error
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response with an error code of 400 (Bad R= equest).

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 If the request contains neither PASSWORD-ALGOR= ITHMS nor PASSWORD-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ALGORITHM, then the request is processed = as though PASSWORD-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ALGORITHM were MD5 (Note that if the orig= inal PASSWORD-ALGORITHMS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attribute did not contain MD5, this will = result in a 400 Bad
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Request in a later step below).

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 If
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only one of PASSWORD-ALGORITHM or PASSWOR= D-ALGORITHMS is present, then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the server MUST generate an error respons= e with an error code of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0400 (Bad Request).

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 If PASSWORD-ALGORITHM does not match one of th= e entries in PASSWORD-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ALGORITHMS, then the server MUST generate= an error response with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an error code of 400 (Bad Request).

This could be further shortened and clarified by using the negation of
the condition we desire:

=C2=A0 =C2=A0o=C2=A0 If the NONCE attribute starts with the "nonce coo= kie" with the
=C2=A0 =C2=A0 =C2=A0 STUN Security Feature "Password algorithm" b= it set to 1, the
=C2=A0 =C2=A0 =C2=A0 server performs these checks in the order specified:
=C2=A0 =C2=A0 =C2=A0 *=C2=A0 If the request contains neither PASSWORD-ALGOR= ITHMS nor PASSWORD-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ALGORITHM, then the request is processed = as though PASSWORD-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ALGORITHM were MD5 (Note that if the orig= inal PASSWORD-ALGORITHMS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attribute did not contain MD5, this will = result in a 400 Bad
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Request in a later step below).

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 Otherwise, unless (1) PASSWORD-ALGORITHM and =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PASSWORD-ALGORITHMS are both present, (2)= PASSWORD-ALGORITHMS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matches the value sent in the response th= at sent this NONCE,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and (3) PASSWORD-ALGORITHM matches one of= the entries in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PASSWORD-ALGORITHMS, the server MUST gene= rate an error
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response with an error code of 400 (Bad R= equest).

--

=C2=A0 =C2=A0 =C2=A0 Servers can
=C2=A0 =C2=A0 =C2=A0 invalidate nonces in order to provide additional secur= ity.

It's not clear what "invalidate" means here.=C2=A0 The text h= as been
talking about nonces expiring, which suggests that it is not a process
that the server actively causes at the time the nonce becomes invalid,
but "invalidate" suggests that the server causes it at the moment= of
invalidation.

=C2=A0 =C2=A0 =C2=A0 See Section 4.3 of [RFC7616] for guidelines.

There is no section 4.3 in RFC 7616.

9.2.5.=C2=A0 Receiving a Response

=C2=A0 =C2=A0If the test succeeds and the "nonce cookie" has
=C2=A0 =C2=A0the STUN Security Feature "Username anonymity" bit s= et to 1 but no
=C2=A0 =C2=A0USERHASH attribute is present, then the client MUST NOT retry = the
=C2=A0 =C2=A0request with a new transaction.

I can find no reference to the server sending USERHASH in a response,
so I don't understand what this means.=C2=A0 I think what was intended = is
"... is set to 1, then the client MUST NOT retry the request using the=
USERHASH attribute."=C2=A0 But that requirement seems to be stated in = the
next paragraph:

=C2=A0 =C2=A0If the response is an error response with an error code of 401=
=C2=A0 =C2=A0(Unauthenticated), the client SHOULD retry the request with a = new
=C2=A0 =C2=A0transaction.=C2=A0 [...]
=C2=A0 =C2=A0If the "nonce cookie" was present and had
=C2=A0 =C2=A0the STUN Security Feature "Username anonymity" bit s= et to 1 then the
=C2=A0 =C2=A0USERHASH attribute MUST be used, else the USERNAME attribute M= UST be
=C2=A0 =C2=A0used.

--

=C2=A0 =C2=A0For all other responses, if the NONCE attribute
=C2=A0 =C2=A0starts with the "nonce cookie" with the STUN Securit= y Feature "User
=C2=A0 =C2=A0anonymity" bit set to 1 but USERHASH is not present, the = response
=C2=A0 =C2=A0MUST be ignored.

As above.

The above texts suggest that there is, or was, an intention that the
server would reflect back the USERHASH value in responses.=C2=A0 But
checking all the mentions of "USERHASH", I can find no text sayin= g
that USERHASH will ever appear in responses.=C2=A0 This design decision
needs to be verified and the text updated correspondingly.

=C2=A0 =C2=A0If the response is an error response with an error code of 400= , and
=C2=A0 =C2=A0does not contains either MESSAGE-INTEGRITY or MESSAGE-INTEGRIT= Y-
=C2=A0 =C2=A0SHA256 attribute then the response MUST be discarded, as if it= was
=C2=A0 =C2=A0never received.=C2=A0 This means that retransmits, if applicab= le, will
=C2=A0 =C2=A0continue.

Some responses generated according to this specification will not pass
the above check.=C2=A0 E.g., from section 9.2.4 item 2:

=C2=A0 =C2=A0o=C2=A0 If the message contains a MESSAGE-INTEGRITY or a MESSA= GE-
=C2=A0 =C2=A0 =C2=A0 INTEGRITY-SHA256 attribute, but is missing either the = USERNAME or
=C2=A0 =C2=A0 =C2=A0 USERHASH, REALM, or NONCE attribute, the server MUST g= enerate an
=C2=A0 =C2=A0 =C2=A0 error response with an error code of 400 (Bad Request)= .=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 response SHOULD NOT include a USERNAME, USERHASH, NONC= E, or REALM.
=C2=A0 =C2=A0 =C2=A0 The response cannot contain a MESSAGE-INTEGRITY or MES= SAGE-
=C2=A0 =C2=A0 =C2=A0 INTEGRITY-SHA256 attribute, as the attributes required= to generate
=C2=A0 =C2=A0 =C2=A0 them are missing.

How does the client effectively receive the error response in this
situation?

10.=C2=A0 ALTERNATE-SERVER Mechanism

To be clearer, the first paragraph should mention that the
ALTERNATE-SERVER attribute carries an IP address, not a domain name
(see section 14.15).=C2=A0 In particular, that disambiguates the test for "same server" in the last paragraph.

=C2=A0 =C2=A0The error response
=C2=A0 =C2=A0message MAY be authenticated; however, there are uses cases fo= r
=C2=A0 =C2=A0ALTERNATE-SERVER where authentication of the response is not p= ossible
=C2=A0 =C2=A0or practical.

s/uses cases/use cases/

=C2=A0 =C2=A0If the client has been redirected to a
=C2=A0 =C2=A0server on which it has already tried this request within the l= ast
=C2=A0 =C2=A0five minutes, [...]

It is a little more formal to say "to a server to which it has already=
sent this request ...".

11.=C2=A0 Backwards Compatibility with RFC 3489

=C2=A0 =C2=A0Any STUN request or indication
=C2=A0 =C2=A0without the magic cookie (see Section 6 of [RFC5389]) over DTL= S MUST
=C2=A0 =C2=A0always result in an error.

The meaning is clear, but in this document, "error" seems to be limited to error responses.=C2=A0 Perhaps better is:

=C2=A0 =C2=A0Any STUN request or indication
=C2=A0 =C2=A0without the magic cookie (see Section 6 of [RFC5389]) over DTL= S MUST
=C2=A0 =C2=A0be considered invalid: requests MUST generate error responses = and
=C2=A0 =C2=A0indications MUST be ignored.

Also, what error code should be used?

13.=C2=A0 STUN Usages

=C2=A0 =C2=A0A usage would also define:

I'm sure you don't want to use the subjunctive mood here, so perhap= s
s/would/will/.=C2=A0 OTOH, you might want to s/would/must/, or "A usag= e
also defines:" to parallel the first sentence of the paragraph.

14.=C2=A0 STUN Attributes

Note that there is an important ordering restriction on attributes:
the attributes MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256, and
FINGERPRINT must, if present, appear finally and in that order.=C2=A0 There=
also seems to be a rule that any attributes which follow one of these
attributes in violation of that rule MUST be ignored.

This is described in those attribute definitions, but it's a global
constraint in the use of attributes, and I think should be pointed out
at this level of the specification.

I'm nervous about the "must be ignored" rule, as it becomes a= little
complicated to do the processing right in all cases.=C2=A0 Perhaps it would=
be better to declare that any such violation invalidates the message
instead?

14.3.=C2=A0 USERNAME

=C2=A0 =C2=A0The value of USERNAME is a variable-length value.

This doesn't actually say what the value is.=C2=A0 Better:

=C2=A0 =C2=A0The value of USERNAME is a variable-length value containing th= e
=C2=A0 =C2=A0authentication username.

14.5.=C2=A0 MESSAGE-INTEGRITY

=C2=A0 =C2=A0Since it uses the SHA1 hash, the HMAC will be
=C2=A0 =C2=A0at 20 bytes.

I think "at" should be omitted.

=C2=A0 =C2=A0The text used as input to HMAC is the STUN message, including = the
=C2=A0 =C2=A0header, up to and including the attribute preceding the MESSAG= E-
=C2=A0 =C2=A0INTEGRITY attribute.=C2=A0 With the exception of the MESSAGE-I= NTEGRITY-
=C2=A0 =C2=A0SHA256 and FINGERPRINT attributes, which appear after MESSAGE-=
=C2=A0 =C2=A0INTEGRITY, agents MUST ignore all other attributes that follow=
=C2=A0 =C2=A0MESSAGE-INTEGRITY.

This paragraph is troublesome.=C2=A0 The matter of attribute ordering is discussed above under section 14.=C2=A0 But the description of calculating<= br> the MAC disagrees with the description in the fourth paragraph.=C2=A0 My suspicion is that the fourth paragraph is correct.=C2=A0 My choice would be=
to omit this paragraph and leave its topics to be dealt with
elsewhere.

=C2=A0 =C2=A0Based on the rules above, the hash used to construct MESSAGE-<= br> =C2=A0 =C2=A0INTEGRITY includes the length field from the STUN message head= er.
=C2=A0 =C2=A0Prior to performing the hash, the MESSAGE-INTEGRITY attribute = MUST be
=C2=A0 =C2=A0inserted into the message (with dummy content).=C2=A0 The leng= th MUST then
=C2=A0 =C2=A0be set to point to the length of the message up to, and includ= ing,
=C2=A0 =C2=A0the MESSAGE-INTEGRITY attribute itself, but excluding any attr= ibutes
=C2=A0 =C2=A0after it.=C2=A0 Once the computation is performed, the value o= f the
=C2=A0 =C2=A0MESSAGE-INTEGRITY attribute can be filled in, and the value of= the
=C2=A0 =C2=A0length in the STUN header can be set to its correct value -- t= he
=C2=A0 =C2=A0length of the entire message.=C2=A0 Similarly, when validating= the
=C2=A0 =C2=A0MESSAGE-INTEGRITY, the length field should be adjusted to poin= t to
=C2=A0 =C2=A0the end of the MESSAGE-INTEGRITY attribute prior to calculatin= g the
=C2=A0 =C2=A0HMAC.=C2=A0 Such adjustment is necessary when attributes, such= as
=C2=A0 =C2=A0FINGERPRINT, appear after MESSAGE-INTEGRITY.

I would rephrase this slightly, borrowing from the second paragraph:

=C2=A0 =C2=A0The text used as input to HMAC is the STUN message, up to and<= br> =C2=A0 =C2=A0including the MESSAGE-INTEGRITY attribute.=C2=A0 The length fi= eld of the
=C2=A0 =C2=A0STUN message header is adjusted to point to the end of the
=C2=A0 =C2=A0MESSAGE-INTEGRITY attribute.=C2=A0 The value of the MESSAGE-IN= TEGRITY
=C2=A0 =C2=A0attribute is set to the dummy value ***.

=C2=A0 =C2=A0Once the computation is performed, the value of the
=C2=A0 =C2=A0MESSAGE-INTEGRITY attribute is filled in, and the value of the=
=C2=A0 =C2=A0length in the STUN header is set to its correct value -- the =C2=A0 =C2=A0length of the entire message.=C2=A0 Similarly, when validating= the
=C2=A0 =C2=A0MESSAGE-INTEGRITY, the length field must be adjusted to point = to
=C2=A0 =C2=A0the end of the MESSAGE-INTEGRITY attribute and the value of th= e
=C2=A0 =C2=A0attribute set to ***=C2=A0 prior to calculating the
=C2=A0 =C2=A0HMAC.=C2=A0 Such adjustment is necessary when attributes, such= as
=C2=A0 =C2=A0FINGERPRINT, appear after MESSAGE-INTEGRITY.

Also, the text doesn't specify what the "dummy content" is!
14.6.=C2=A0 MESSAGE-INTEGRITY-SHA256

This section has the same problems regarding the HMAC calculation as
section 14.5.

The discussion of truncation seems to assume that the reader already
fully understands the concept.=C2=A0 Better would be to explain it
explicitly, since that doesn't take more words:

=C2=A0 =C2=A0The MESSAGE-INTEGRITY-SHA256 attribute can be present in any S= TUN
=C2=A0 =C2=A0message type.=C2=A0 The MESSAGE-INTEGRITY-SHA256 attribute con= tains an
=C2=A0 =C2=A0initial portion of the HMAC-SHA-256 [RFC2104] of the STUN mess= age.
=C2=A0 =C2=A0The value will be at most 32 bytes and MUST be a positive mult= iple
=C2=A0 =C2=A0of 4 bytes.=C2=A0 The value must be the full 32 bytes unless t= he STUN
=C2=A0 =C2=A0usage explicitly specifies that truncation is allowed.=C2=A0 U= sages may
=C2=A0 =C2=A0specify a minimum length longer than 4 bytes.

14.7.=C2=A0 FINGERPRINT

=C2=A0 =C2=A0The FINGERPRINT attribute MAY be present in all STUN messages.= =C2=A0 The
=C2=A0 =C2=A0value of the attribute is computed as the CRC-32 of the STUN m= essage
=C2=A0 =C2=A0up to (but excluding) the FINGERPRINT attribute itself, [...]<= br>
Note that unlike the MESSAGE-INTEGRITY attributes, the FINGERPRINT
calculation does not prepare the text by adjusting the Length field of
the header.=C2=A0 Verify that this is what is intended and perhaps mention<= br> it explicitly.

=C2=A0 =C2=A0[...] up to (but excluding) the FINGERPRINT attribute itself, = XOR'ed with
=C2=A0 =C2=A0the 32-bit value 0x5354554e (the XOR helps in cases where an =C2=A0 =C2=A0application packet is also using CRC-32 in it).

This is awkward.=C2=A0 Perhaps unpack it into:

=C2=A0 =C2=A0The value of the attribute is computed as the CRC-32 of the ST= UN
=C2=A0 =C2=A0message up to (but excluding) the FINGERPRINT attribute itself= ,
=C2=A0 =C2=A0XOR'ed with the 32-bit value 0x5354554e.=C2=A0 (The XOR op= eration
=C2=A0 =C2=A0ensures that the FINGERPRINT test will not report a false posi= tive
=C2=A0 =C2=A0on a packet containing a CRC-32 generated by an application =C2=A0 =C2=A0protocol.)

14.8.=C2=A0 ERROR-CODE

=C2=A0 =C2=A0The Reserved bits SHOULD be 0, and are for alignment on 32-bit=
=C2=A0 =C2=A0boundaries.=C2=A0 Receivers MUST ignore these bits.=C2=A0 The = Class represents
=C2=A0 =C2=A0the hundreds digit of the error code.=C2=A0 The value MUST be = between 3
=C2=A0 =C2=A0and 6.=C2=A0 The Number represents the error code modulo 100, = and its
=C2=A0 =C2=A0value MUST be between 0 and 99.

How is Number encoded?=C2=A0 I suspect that binary is intended, but it is an 8-bit field holding a two-digit decimal number, and so might
plausibly be encoded as two nibbles containing the two digits.

14.9.=C2=A0 REALM

=C2=A0 =C2=A0Presence in certain
=C2=A0 =C2=A0error responses indicates that the server wishes the client to= use a
=C2=A0 =C2=A0long-term credential for authentication.

I think you mean s/a long-term credential/a long-term credential in
that realm/.

14.10.=C2=A0 NONCE

=C2=A0 =C2=A0Note that this means that the NONCE attribute will not contain=
=C2=A0 =C2=A0actual quote characters.

More exactly, "will not contain the surrounding quote characters"= .

But some thought should be given to using the same wording in 14.9 and
14.10.

14.11.=C2=A0 PASSWORD-ALGORITHMS

=C2=A0 =C2=A0The parameters start with the actual length of the
=C2=A0 =C2=A0parameters as a 16-bit value, followed by the parameters that = are
=C2=A0 =C2=A0specific to each algorithm.

"actual length" should be "length (prior to padding)".<= br>
14.12.=C2=A0 PASSWORD-ALGORITHM

=C2=A0 =C2=A0The parameters starts with the actual length of the
=C2=A0 =C2=A0parameters as a 16-bit value, followed by the parameters that = are
=C2=A0 =C2=A0specific to the algorithm.

"actual length" should be "length (prior to padding)".<= br>
15.1.2.=C2=A0 Inside Attacks

=C2=A0 =C2=A0Fortunately, STUN
=C2=A0 =C2=A0requests can be processed statelessly by a server, making such=
=C2=A0 =C2=A0attacks hard to launch.

Actually, such attacks are easy to launch, but "hard to launch
effectively".

=C2=A0 =C2=A0This attack is mitigated by ingress source address filtering.<= br>
I would help to explain who is filtering and on what basis to
implement this mitigation.

15.2.4.=C2=A0 Attack IV: Eavesdropping

=C2=A0 =C2=A0In this attack, the attacker forces the client to use a reflex= ive
=C2=A0 =C2=A0address that routes to itself.

"itself" usually refers to the subject of the verb in its clause,=
which is "address".=C2=A0 But I think "attacker" is int= ended, in which case
you can phrase it "that routes to the attacker itself".

17.1.=C2=A0 STUN Security Features Registry

=C2=A0 =C2=A0New Security Features are assigned by a Standard Action [RFC81= 26].

s/Standard Action/Standards Action/ per RFC 8u126 section 4.9.

17.3.2.=C2=A0 New Attributes

=C2=A0 =C2=A00xXXXX: PASSSORD-ALGORITHMS

s/PASSSORD/PASSWORD/

17.5.=C2=A0 Password Algorithm Registry

I think you want to title this registry "Stun password algorithm regis= try".

17.6.=C2=A0 STUN UDP and TCP Port Numbers

This section should state that it is updating "Service Name and
Transport Protocol Port Number Registry".

18.=C2=A0 Changes since RFC 5389

The following items should contain proper references to the mentioned RFCs:=

=C2=A0 =C2=A0o=C2=A0 Added support for DTLS-over-UDP (RFC 6347).

=C2=A0 =C2=A0o=C2=A0 Aligned the RTO calculation with RFC 6298.

=C2=A0 =C2=A0o=C2=A0 Added support for STUN URI (RFC 7064).

=C2=A0 =C2=A0o=C2=A0 Updated the PRECIS support to RFC 8265.

[END]



--001a11470a2660759c0565e8ce57--