From nobody Sun Apr 1 09:56:43 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 262AD126DFF for ; Sun, 1 Apr 2018 09:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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=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 RWjckcUe0rWt for ; Sun, 1 Apr 2018 09:56:40 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 4E751126DCA for ; Sun, 1 Apr 2018 09:56:40 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id q71-v6so11247158oic.6 for ; Sun, 01 Apr 2018 09:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HJOvIYf0ySfy36f9gEaDvIk3sH3qCdygcpbz2M7YIXU=; b=Gbni0fBChd6fkt6mpDvSjKxHbaJiMqUsABB8R9c9E8LifdBGS1BZK94t2sGPDCLpIj dgqLoDD9qhQBAl/N+iWGpXCQxTtltwSLlx0Hj09+zc/ZL9oJ/3EJUKYV7u7nLkLr9uJy SBTNqO/KW7tQk2eCW7yrT+cHLAja6Bvkq7DN65VYjn8etYj6tEzq4NWZcl7Ejgz66kcz 73/xQ+Q5FWQDncsT46uZmHW5MIpmOsuha4SZtBjVEF/Jq+iaQATLLbt7adiUPO+aq2Rc pbmWLcLDu6L7UeUHGyT1mE5fJg+f2TJ9n37z5Xrp9tn0KsdP8XV39eLwnLcr7EtGPtyh nQ4g== 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=HJOvIYf0ySfy36f9gEaDvIk3sH3qCdygcpbz2M7YIXU=; b=HcVfl2B7Fc6tcAKYILrvetz4xXNIM5nPPRxcerT5HWrNrdhkIbN/6MzjIWOYmiq322 zcoPkP/patE0VxVXVVnxQirxeFmaYgUExq132VXZOf2IDEeABc3fsXzHJTK/fGR4HcSw drBy9RyHrB0UkH2ZIsFta/GsXWhY5Odwz0Atv/AYN3z9xaPpYxkjwx10SzluDpPX8/ob ndzg54a7p+9k+XnokI2mbaL43w9dtAq53fNLsZQqXwVej56mdfJ7qEWWJtp1vCQyG45V ASKHkoPHpM2vi9FZY5MUHqkr745iN1c22IorAfjHucI9PiyysapuRj/D3eb00AQvvfVS PpGA== X-Gm-Message-State: ALQs6tDdmaymTT1li7UKbXXAr2KN2vwNwu/tD6GH9XwdL1xX5il5T/tT zYQ3K4czUxUMXvnO5d4qQtXlsd0Q0+5/y3xo5FV41Q== X-Google-Smtp-Source: AIpwx4+6VzpZ7Qq1/goVbZVcEXgmdFskHvGd4RlUkr18hwG635SDBef/n9hu+tlXRTaH3WIiPa18VERpj4DPJcQzCcs= X-Received: by 2002:aca:d0d1:: with SMTP id j78-v6mr3377073oiy.52.1522601799534; Sun, 01 Apr 2018 09:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.203.132 with HTTP; Sun, 1 Apr 2018 09:56:18 -0700 (PDT) In-Reply-To: References: <8d57a9e5-5697-38f5-1b85-bf55930c6461@akamai.com> From: Simon Perreault Date: Sun, 1 Apr 2018 12:56:18 -0400 Message-ID: To: Justin Uberti Cc: "Konda, Tirumaleswar Reddy" , Brandon Williams , Nils Ohlmeier , "Cullen Jennings (fluffy)" , Eric Rescorla , tram@ietf.org Content-Type: multipart/alternative; boundary="000000000000657af70568cc5bf0" Archived-At: Subject: Re: [tram] Allow TURN to forward inbound connectivity checks without permission 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, 01 Apr 2018 16:56:42 -0000 --000000000000657af70568cc5bf0 Content-Type: text/plain; charset="UTF-8" 2018-03-31 18:50 GMT-04:00 Justin Uberti : > As Brandon says, the ufrag/pwd info could be posted along with the address > of the server, so while this raises the bar, it doesn't solve the problem. > > I agree with Brandon that the only reasonable way to completely contain > this is some sort of server policy, e.g., some time window or session count > after which the permission bypass expires, meaning that someone running a > server would have to be continually requesting new allocations and posting > their address/credentials. > Do we need to completely contain this? Is there actually a problem with the proposal? Allowing STUN in allows someone to run a server if and only if the protocol masquerades as STUN. It doesn't allow a user to run an arbitrary server. For this to be exploitable, the user would also need to control the clients in some way. I can't think of a way this could be exploited practically. Maybe I lack imagination? Simon --000000000000657af70568cc5bf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -03-31 18:50 GMT-04:00 Justin Uberti <juberti@google.com>:<= br>
As Brandon says, the ufr= ag/pwd info could be posted along with the address of the server, so while = this raises the bar, it doesn't solve the problem.

I= agree with Brandon that the only reasonable way to completely contain this= is some sort of server policy, e.g., some time window or session count aft= er which the permission bypass expires, meaning that someone running a serv= er would have to be continually requesting new allocations and posting thei= r address/credentials.

Do we need to completely contain this? Is there actually a= problem with the proposal?

Allowing STUN in allows someone to run a server if an= d only if the protocol masquerades as STUN. It doesn't allow a user to = run an arbitrary server. For this to be exploitable, the user would also ne= ed to control the clients in some way.

=
I can't think of a way this could be e= xploited practically. Maybe I lack imagination?

Simon
--000000000000657af70568cc5bf0-- From nobody Sun Apr 1 15:09:58 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 945B5126D73 for ; Sun, 1 Apr 2018 15:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CB2yA0lhUG9v for ; Sun, 1 Apr 2018 15:09:54 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 4EC44120721 for ; Sun, 1 Apr 2018 15:09:54 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id v134so7409613vkd.10 for ; Sun, 01 Apr 2018 15:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qwijxSn1+CwEkoRYY5k/MHQ5whArzd1zKiOokQQJ3jQ=; b=VfZM+qxnqf/Qu8T42P7LOk8ezkA4xDAGjjVlFY8jsQ70q4SCK+t0xSUAPyeX3ePDV3 0dChYx1DTBTsLhEQ0vsOUo7NQyMMQYWqpc2Ye/092R4wG4BHm/rn7uOlCZTeYgCHF6zs nRUMHphD4grzef0OfS++dSLJY0aOskfxICZa0Dy5sC/Jv13PVIjZlaLeoaBFwtv21Rzp nZG3LtB0pvN10/LeGxiwGuOA2uOHs68ZOBW8UCPWGI6AZSFTn96CGTyfQC3rOP/5KiPm E2c1LCKiecTPIuw1GtIvpc5Qwgntf1m5xP161SyhGUAmTRgCcdQauPRYC0x+PnGLslbu h90w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qwijxSn1+CwEkoRYY5k/MHQ5whArzd1zKiOokQQJ3jQ=; b=ZrFKxazc48iQ0WKsakGNVD7n27Lp+XCB/u6gy4E3XIZeGB4ZcAs4C5uqwMCfRskcr1 P6X+yrKo4jKKpA7fjuofEIrkBh0oP4Eus8fXoh8YLb59WvD92l+KQ4mroW43bOlJayH4 6+2aY6SVSjsfMEqBM0PfxVIANNQr1zWYxAPnavmO6WhxrOGm0Z0SnZ8jeNaTKK79FlVq TB4fEWTuPAJLa2mr09IR0Xrar24bk2t68AUVNkBdtcuek2Zl6C2UESVvakPpM4xz0Yk5 Ak4QE4quuJgZY3t4vJlrqOWUhJ0cQZOAjht3FHC/KOjIZSOglzBxeyyR4qCKRtXZHuIe va+A== X-Gm-Message-State: ALQs6tATyz4i61gmUg0wz8hRcLxJ1dl8kyUd/160hYSQ/+gXv6eKx9wj 5vLC0i5ZxexWmv8VnZ/Fm2QZfeZIvB3CijWuaL37ww== X-Google-Smtp-Source: AIpwx49xNVOR3hlshtVk5NO5iO+QOuhg20+KfGCJBSfeDHSWZyHt1vlczn66JEq5Qyuo0R6QS/RsbzYMKvpd1Y/tzfU= X-Received: by 10.31.157.216 with SMTP id g207mr3918362vke.111.1522620592821; Sun, 01 Apr 2018 15:09:52 -0700 (PDT) MIME-Version: 1.0 References: <8d57a9e5-5697-38f5-1b85-bf55930c6461@akamai.com> In-Reply-To: From: Justin Uberti Date: Sun, 01 Apr 2018 22:09:40 +0000 Message-ID: To: Simon Perreault Cc: TirumaleswarReddy_Konda@mcafee.com, Brandon Williams , Nils Ohlmeier , "Cullen Jennings (fluffy)" , Eric Rescorla , tram@ietf.org Content-Type: multipart/alternative; boundary="001a1142763490b1840568d0bb5a" Archived-At: Subject: Re: [tram] Allow TURN to forward inbound connectivity checks without permission 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, 01 Apr 2018 22:09:56 -0000 --001a1142763490b1840568d0bb5a Content-Type: text/plain; charset="UTF-8" On Sun, Apr 1, 2018 at 9:56 AM Simon Perreault wrote: > 2018-03-31 18:50 GMT-04:00 Justin Uberti : > >> As Brandon says, the ufrag/pwd info could be posted along with the >> address of the server, so while this raises the bar, it doesn't solve the >> problem. >> >> I agree with Brandon that the only reasonable way to completely contain >> this is some sort of server policy, e.g., some time window or session count >> after which the permission bypass expires, meaning that someone running a >> server would have to be continually requesting new allocations and posting >> their address/credentials. >> > > Do we need to completely contain this? Is there actually a problem with > the proposal? > > Allowing STUN in allows someone to run a server if and only if the > protocol masquerades as STUN. It doesn't allow a user to run an arbitrary > server. For this to be exploitable, the user would also need to control the > clients in some way. > > I can't think of a way this could be exploited practically. Maybe I lack > imagination? > I don't think this is fatal to the proposal. I just think that we need to be up front that this is a potential loophole, and have some explicit discussion in the document of how one might solve this problem should it become necessary (e.g., with server policy). --001a1142763490b1840568d0bb5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Apr 1, 2018 at 9:56 AM Simon Perreault <sperreault@jive.com> wrote:
2018-03-31 18:50 GMT-04:00 Justin Uberti <juberti@google.com>= :
As Brandon says= , the ufrag/pwd info could be posted along with the address of the server, = so while this raises the bar, it doesn't solve the problem.

I agree with Brandon that the only reasonable way to completely con= tain this is some sort of server policy, e.g., some time window or session = count after which the permission bypass expires, meaning that someone runni= ng a server would have to be continually requesting new allocations and pos= ting their address/credentials.

Do we need to completely contain this? Is there act= ually a problem with the proposal?

Allowing STUN in allows someone to run a serve= r if and only if the protocol masquerades as STUN. It doesn't allow a u= ser to run an arbitrary server. For this to be exploitable, the user would = also need to control the clients in some way.

I can't think of a way this cou= ld be exploited practically. Maybe I lack imagination?

I don't think this is fatal to the proposal. I = just think that we need to be up front that this is a potential loophole, a= nd have some explicit discussion in the document of how one might solve thi= s problem should it become necessary (e.g., with server policy).
--001a1142763490b1840568d0bb5a-- From nobody Mon Apr 2 01:03: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 D21161242F5 for ; Mon, 2 Apr 2018 01:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 XL2dkn384Tuw for ; Mon, 2 Apr 2018 01:03:48 -0700 (PDT) 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 CE6241204DA for ; Mon, 2 Apr 2018 01:03:47 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1522656226; 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=M FnWZEDFdBDNUgH55TL+NyFFUYGjrMbUclEMOx4eA7 o=; b=DtxAmda29QmAUG4AmWbGc7kQTYNXUNj+sr+AnKebpXSf osTJg0CXSGsFGes/+3sv3oic44pZeMk7jIwg0krRNGE5wvKfDv fhxZ6CeDX6UnmkjQtWJOtSQfLyboMgEOeZR1BN4c9rc4ePZzk3 z3c/AFpHYJivqTL69ldD3m49Ujk= 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 2c3e_bce5_47925b02_46b2_452e_96cb_88385ddb893a; Mon, 02 Apr 2018 03:03:46 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Apr 2018 02:03:45 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Apr 2018 02:03:44 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 2 Apr 2018 02:03:44 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Apr 2018 02:03:42 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1444.namprd16.prod.outlook.com (10.172.207.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.10; Mon, 2 Apr 2018 08:03:41 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0631.013; Mon, 2 Apr 2018 08:03:41 +0000 From: "Konda, Tirumaleswar Reddy" To: Noriyuki Torii CC: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt Thread-Index: AQHTvpVCIExz03qGwU2I9I0I/uh+eqPVrxXQgAEO0ACADXSKkIABEIIAgAfx+HA= Date: Mon, 2 Apr 2018 08:03:41 +0000 Message-ID: References: <152136260256.18150.10551009018364033510@ietfa.amsl.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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1444; 7:InSaga/ViRm3Ua/h3BUQi7g/QX+c6JUxFJWHGnMrf+Gbnka2pl3FhQ63cG8MEInDfP08FJdayjJG9FEiJWKBeIECRVdcZ7i9cTfAHY+ayaBzbmwHE6roVIA1pdcNrGUBkEqCtVzjwOvR8tluFw6kR1xqObEuDdakk4fewtNk6ZWaIEMvsaLQlCMGydE+LYrKs6OlAEQFh6ICS1oPC5MV/AkzUvpiO2zMMA9vvIWcsvKp41TIX/00B3VL2YWoGnTe x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 07e44546-9fe7-4e8d-885c-08d598703fe3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1444; x-ms-traffictypediagnostic: BN6PR16MB1444: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(85827821059158)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR16MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1444; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(39380400002)(366004)(376002)(199004)(189003)(377424004)(13464003)(32952001)(966005)(2900100001)(106356001)(8936002)(81156014)(81166006)(8676002)(7696005)(7736002)(2906002)(53546011)(105586002)(33656002)(478600001)(72206003)(26005)(25786009)(4326008)(6506007)(59450400001)(186003)(66066001)(14454004)(102836004)(76176011)(11346002)(6116002)(446003)(1411001)(3846002)(316002)(551544002)(476003)(486005)(486005)(345774005)(6436002)(305945005)(74316002)(6306002)(9686003)(6916009)(80792005)(5660300001)(55016002)(86362001)(99286004)(229853002)(97736004)(6246003)(5250100002)(39060400002)(93886005)(53936002)(3660700001)(3280700002)(68736007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1444; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: uXkeYJ+HaY7N5f2X8fh8PLR9W93Cxj08cp2G2FU3Z/grGKciodCUB0E9u75CHg8Nl4T57FbjyRwDSvy7TPSGs1x8see5CoQJ/gN+T2Of8+/DEBVZ8Lt+PnzCij5fA9w0KaJoRqk0iFQvqWeMm63QUovsfpi3VeWmEOlU8AHUvOqWvIM26opOR4agXVj5xo1DdTo5pP+5i0d+NwOw7MFnE7aqxDPzCzs2lxaROLsI46hvSmC4Zn6TRnebrOtNF60xeIpyEoC9A9+9qTeaF0FEFO0MHqrdrKNlDqfBuExPQuOreQGgdxSQGN6OMWUWOpJb/zTAA/yCS0DYL8HyqRdCbhdFPRfrQQuOjWIMcQUth7VqBUeKZwb5Vwlup45W4/QF8VbF6Y+fbbqlfVXUSGW0zgiO7GXuE+FkKeJMcSEebNc= 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: 07e44546-9fe7-4e8d-885c-08d598703fe3 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2018 08:03:41.6336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1444 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 <6254> : inlines <6533> : streams <1782964> : uri <2619006> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.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, 02 Apr 2018 08:03:50 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOb3JpeXVraSBUb3JpaSBbbWFp bHRvOnRvcmlpMDU3M0BnbWFpbC5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjgsIDIw MTggMTI6MTMgUE0NCj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQo+IENjOiB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMTUudHh0DQo+ IA0KPiBIaSBUaXJ1LA0KPiANCj4gVGhhbmsgeW91IGZvciB0aGUgdXBkYXRlLg0KPiBJIGhlc2l0 YXRlIHRvIHNheSBidXQgSSBub3RpY2VkIEkndmUgbWlzc2VkIG9uZSBtb3JlIHBvaW50Lg0KPiAN Cj4gVGhhdCBpcyB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gMTIuNg0KPiANCj4gPiAg IFRoZSByZWNlaXZlciBvZiB0aGUgQ2hhbm5lbERhdGEgbWVzc2FnZSB1c2VzIHRoZSBmaXJzdCB0 d28gYml0cyB0bw0KPiA+ICAgZGlzdGluZ3Vpc2ggaXQgZnJvbSBTVFVOLWZvcm1hdHRlZCBtZXNz YWdlcywgYXMgZGVzY3JpYmVkIGFib3ZlLiAgSWYNCj4gPiAgIHRoZSBtZXNzYWdlIHVzZXMgYSB2 YWx1ZSBpbiB0aGUgcmVzZXJ2ZWQgcmFuZ2UgKDB4ODAwMCB0aHJvdWdoDQo+ID4gICAweEZGRkYp LCB0aGVuIHRoZSBtZXNzYWdlIGlzIHNpbGVudGx5IGRpc2NhcmRlZC4NCj4gDQo+IEFwcGFyZW50 bHksIGFib3ZlIHBhcmFncmFwaCBhbHNvIG5lZWQgdXBkYXRlIHRvIGFsaWduIHdpdGggUkZDNzk4 MyBhbmQgYWxzbw0KPiBsYXN0IHVwZGF0ZSBvZiBzZWN0aW9uIDEyLg0KDQpUaGFua3MsIGZpeGVk IGluIG15IGxvY2FsIGNvcHkuDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+IFJlZ2FyZHMsDQo+ IE5vcml5dWtpIFRvcmlpDQo+IA0KPiANCj4gMjAxOC0wMy0yNyAyMzoyOSBHTVQrMDk6MDAgS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVl LmNvbT46DQo+ID4gVGhhbmtzIE5vcml5dWtpIFRvcmlpLCBhZGRyZXNzZWQgdGhlIGNvbW1lbnRz IGluIHRoZSBuZXcgcmV2aXNpb24uDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gLVRpcnUNCj4gPg0K PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBOb3JpeXVraSBUb3Jp aSBbbWFpbHRvOnRvcmlpMDU3M0BnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IE1vbmRheSwgTWFyY2gg MTksIDIwMTggNjoyOSBBTQ0KPiA+PiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCj4gPj4gQ2M6IHRyYW1AaWV0Zi5vcmcN Cj4gPj4gU3ViamVjdDogUmU6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVy bmJpcy0xNS50eHQNCj4gPj4NCj4gPj4gSGkgVGlydSwNCj4gPj4NCj4gPj4gSSBjaGVja2VkIHVw ZGF0ZWQgSS1EIGFuZCBmb3VuZCBzb21lIG1vcmUgcG9pbnRzIGluIHNlY3Rpb24gMTIgYmVsb3cu DQo+ID4+DQo+ID4+ID4gICAgICAweDQwMDAgdGhyb3VnaCAweDRGRkY6IFRoZXNlIHZhbHVlcyBh cmUgdGhlIGFsbG93ZWQgY2hhbm5lbA0KPiA+PiA+ICAgICAgbnVtYmVycyAoMTYsMzg0IHBvc3Np YmxlIHZhbHVlcykuDQo+ID4+ICAgICAgICAgICAgICAgICB+fn5+fn4NCj4gPj4gVGhpcyB2YWx1 ZSBhbHNvIG5lZWQgdG8gYmUgYW1lbmRlZCB0byA0LDA5Ni4NCj4gPj4NCj4gPj4gPiAgICAgIDB4 ODAwMCB0aHJvdWdoIDB4RkZGRjogVGhlc2UgdmFsdWVzIGFyZSByZXNlcnZlZCBmb3IgZnV0dXJl IHVzZS4NCj4gPj4NCj4gPj4gVGhpcyBsaW5lIGNhbiBiZSByZW1vdmVkIG5vdyBiZWNhdXNlIHRo ZSBwcmV2aW91cyBzZW50ZW5jZSBpbXBseSBpdCwgdG9vLg0KPiA+Pg0KPiA+PiBBbmQgYWxzbywg SSB0aGluayBpdCBtYXkgYmUgcHJlZmVyYWJsZSBpZiB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCBp cw0KPiA+PiB1cGRhdGVkIHNvIGFzIHRvIGFsaWdubWVudCB0byBSRkMgNzk4My4NCj4gPj4NCj4g Pj4gPiAgIEJlY2F1c2Ugb2YgdGhpcyBkaXZpc2lvbiwgQ2hhbm5lbERhdGEgbWVzc2FnZXMgY2Fu IGJlIGRpc3Rpbmd1aXNoZWQNCj4gPj4gPiAgIGZyb20gU1RVTi1mb3JtYXR0ZWQgbWVzc2FnZXMg KGUuZy4sIEFsbG9jYXRlIHJlcXVlc3QsIFNlbmQNCj4gPj4gPiAgIGluZGljYXRpb24sIGV0Yy4p IGJ5IGV4YW1pbmluZyB0aGUgZmlyc3QgdHdvIGJpdHMgb2YgdGhlIG1lc3NhZ2U6DQo+ID4+ID4N Cj4gPj4gPiAgICAgIDBiMDA6IFNUVU4tZm9ybWF0dGVkIG1lc3NhZ2UgKHNpbmNlIHRoZSBmaXJz dCB0d28gYml0cyBvZiBhIFNUVU4tDQo+ID4+ID4gICAgICBmb3JtYXR0ZWQgbWVzc2FnZSBhcmUg YWx3YXlzIHplcm8pLg0KPiA+PiA+DQo+ID4+ID4gICAgICAwYjAxOiBDaGFubmVsRGF0YSBtZXNz YWdlIChzaW5jZSB0aGUgY2hhbm5lbCBudW1iZXIgaXMgdGhlIGZpcnN0DQo+ID4+ID4gICAgICBm aWVsZCBpbiB0aGUgQ2hhbm5lbERhdGEgbWVzc2FnZSBhbmQgY2hhbm5lbCBudW1iZXJzIGZhbGwg aW4gdGhlDQo+ID4+ID4gICAgICByYW5nZSAweDQwMDAgLSAweDdGRkYpLg0KPiA+PiA+DQo+ID4+ ID4gICAgICAwYjEwOiBSZXNlcnZlZA0KPiA+PiA+DQo+ID4+ID4gICAgICAwYjExOiBSZXNlcnZl ZA0KPiA+PiA+DQo+ID4+ID4gICBUaGUgcmVzZXJ2ZWQgdmFsdWVzIG1heSBiZSB1c2VkIGluIHRo ZSBmdXR1cmUgdG8gZXh0ZW5kIHRoZSByYW5nZSBvZg0KPiA+PiA+ICAgY2hhbm5lbCBudW1iZXJz LiAgVGh1cywgYW4gaW1wbGVtZW50YXRpb24gTVVTVCBOT1QgYXNzdW1lIHRoYXQgYQ0KPiBUVVJO DQo+ID4+ID4gICBtZXNzYWdlIGFsd2F5cyBzdGFydHMgd2l0aCBhIDAgYml0Lg0KPiA+Pg0KPiA+ PiBJIGd1ZXNzIGl0IGNvdWxkIGJlDQo+ID4+DQo+ID4+ICAgICBBY2NvcmRpbmcgdG8gUkZDIDc5 ODMsIENoYW5uZWxEYXRhIG1lc3NhZ2VzIGNhbiBiZSBkaXN0aW5ndWlzaGVkDQo+ID4+ICAgICBm cm9tIG90aGVyIG11bHRpcGxleGVkIHByb3RvY29scyBieSBleGFtaW5pbmcgdGhlIGZpcnN0IGJ5 dGUgb2YgdGhlDQo+ID4+ICAgICBtZXNzYWdlOg0KPiA+Pg0KPiA+PiAgICAgICAgICAgWzAuLjNd ICBTVFVODQo+ID4+ICAgICAgICAgWzE2Li4xOV0gIFpSVFANCj4gPj4gICAgICAgICBbMjAuLjYz XSAgRFRMUw0KPiA+PiAgICAgICAgIFs2NC4uNzldICBUVVJOIENoYW5uZWwNCj4gPj4gICAgICAg WzEyOC4uMTkxXSAgUlRQL1JUQ1ANCj4gPj4gICAgICAgICAgIG90aGVycyAgcmVzZXJ2ZWQsIE1V U1QgYmUgZHJvcHBlZCBhbmQgYW4gYWxlcnQgTUFZIGJlDQo+ID4+IGxvZ2dlZA0KPiA+Pg0KPiA+ PiAgICAgUmVzZXJ2ZWQgdmFsdWVzIG1heSBiZSB1c2VkIGluIHRoZSBmdXR1cmUgYnkgb3RoZXIg cHJvdG9jb2xzLg0KPiA+PiAgICAgVGh1cywgYW4gaW1wbGVtZW50YXRpb24gTVVTVCBjb21wbHkg dGhlIGRpc2NyaW1pbmF0aW9uIGFib3ZlLg0KPiA+Pg0KPiA+Pg0KPiA+PiBGaW5hbGx5LCBpbiBz ZWN0aW9uIDE4LCB0aGUgZXhhbXBsZSBSZWZyZXNoIHJlcXVlc3QgaW4gdGhlIGRpYWdyYW0gb2YN Cj4gPj4gdGhlIHBhZ2UgNjcgZG9lc24ndCBoYXZlIHRoZSBQQVNTV09SRC1BTEdPUklUSE1TIGF0 dHJpYnV0ZQ0KPiA+PiBuZXZlcnRoZWxlc3MgaXQgaGFzIHRoZSBQQVNTV09SRC1BTEdPUklUSE0g YXR0cmlidXRlcywgYWxzbyBuZWVkIHRvIGJlDQo+IGZpeGVkLg0KPiA+Pg0KPiA+PiBSZWdhcmRz LA0KPiA+PiBOb3JpeXVraSBUb3JpaQ0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tDQo+ID4+ DQo+ID4+IDIwMTgtMDMtMTggMTc6NTAgR01UKzA5OjAwIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVk ZHkNCj4gPj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQG1jYWZlZS5jb20+Og0KPiA+PiA+IFRo aXMgcmV2aXNpb24gYWRkcmVzc2VzIGNvbW1lbnRzIGZyb20gTWFyaywgS2FybCBhbmQgTm9yaXl1 a2kgVG9yaWkuDQo+ID4+ID4NCj4gPj4gPiAtVGlydQ0KPiA+PiA+DQo+ID4+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+IEZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC0NCj4gPj4gPj4gZHJhZnRzQGlldGYu b3JnDQo+ID4+ID4+IFNlbnQ6IFN1bmRheSwgTWFyY2ggMTgsIDIwMTggODo0MyBBTQ0KPiA+PiA+ PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+ID4+ID4+IENjOiB0cmFtQGlldGYub3JnDQo+ ID4+ID4+IFN1YmplY3Q6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVybmJp cy0xNS50eHQNCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4gPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9y aWVzLg0KPiA+PiA+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUVVJOIFJldmlz ZWQgYW5kIE1vZGVybml6ZWQgV0cgb2YNCj4gPj4gPj4gdGhlIElFVEYuDQo+ID4+ID4+DQo+ID4+ ID4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogVHJhdmVyc2FsIFVzaW5nIFJlbGF5cyBhcm91 bmQgTkFUIChUVVJOKTogUmVsYXkNCj4gRXh0ZW5zaW9ucw0KPiA+PiA+PiB0byBTZXNzaW9uIFRy YXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikNCj4gPj4gPj4gICAgICAgICBBdXRob3Jz ICAgICAgICAgOiBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPj4gPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICBBbGFuIEpvaG5zdG9uDQo+ID4+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg UGhpbGlwIE1hdHRoZXdzDQo+ID4+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSm9uYXRo YW4gUm9zZW5iZXJnDQo+ID4+ID4+ICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYt dHJhbS10dXJuYmlzLTE1LnR4dA0KPiA+PiA+PiAgICAgICBQYWdlcyAgICAgICAgICAgOiA4NA0K PiA+PiA+PiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE4LTAzLTE4DQo+ID4+ID4+DQo+ID4+ ID4+IEFic3RyYWN0Og0KPiA+PiA+PiAgICBJZiBhIGhvc3QgaXMgbG9jYXRlZCBiZWhpbmQgYSBO QVQsIHRoZW4gaW4gY2VydGFpbiBzaXR1YXRpb25zIGl0IGNhbg0KPiA+PiA+PiAgICBiZSBpbXBv c3NpYmxlIGZvciB0aGF0IGhvc3QgdG8gY29tbXVuaWNhdGUgZGlyZWN0bHkgd2l0aCBvdGhlciBo b3N0cw0KPiA+PiA+PiAgICAocGVlcnMpLiAgSW4gdGhlc2Ugc2l0dWF0aW9ucywgaXQgaXMgbmVj ZXNzYXJ5IGZvciB0aGUgaG9zdCB0byB1c2UNCj4gPj4gPj4gICAgdGhlIHNlcnZpY2VzIG9mIGFu IGludGVybWVkaWF0ZSBub2RlIHRoYXQgYWN0cyBhcyBhIGNvbW11bmljYXRpb24NCj4gPj4gPj4g ICAgcmVsYXkuICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHByb3RvY29sLCBjYWxsZWQg VFVSTiAoVHJhdmVyc2FsDQo+ID4+ID4+ICAgIFVzaW5nIFJlbGF5cyBhcm91bmQgTkFUKSwgdGhh dCBhbGxvd3MgdGhlIGhvc3QgdG8gY29udHJvbCB0aGUNCj4gPj4gPj4gICAgb3BlcmF0aW9uIG9m IHRoZSByZWxheSBhbmQgdG8gZXhjaGFuZ2UgcGFja2V0cyB3aXRoIGl0cyBwZWVycyB1c2luZw0K PiA+PiA+PiAgICB0aGUgcmVsYXkuICBUVVJOIGRpZmZlcnMgZnJvbSBzb21lIG90aGVyIHJlbGF5 IGNvbnRyb2wgcHJvdG9jb2xzIGluDQo+ID4+ID4+ICAgIHRoYXQgaXQgYWxsb3dzIGEgY2xpZW50 IHRvIGNvbW11bmljYXRlIHdpdGggbXVsdGlwbGUgcGVlcnMgdXNpbmcgYQ0KPiA+PiA+PiAgICBz aW5nbGUgcmVsYXkgYWRkcmVzcy4NCj4gPj4gPj4NCj4gPj4gPj4gICAgVGhlIFRVUk4gcHJvdG9j b2wgd2FzIGRlc2lnbmVkIHRvIGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgSUNFDQo+ID4+ID4+ICAg IChJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudCkgYXBwcm9hY2ggdG8gTkFU IHRyYXZlcnNhbCwNCj4gPj4gPj4gICAgdGhvdWdoIGl0IGFsc28gY2FuIGJlIHVzZWQgd2l0aG91 dCBJQ0UuDQo+ID4+ID4+DQo+ID4+ID4+ICAgIFRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIFJGQyA1 NzY2IGFuZCBSRkMgNjE1Ni4NCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4gPj4gVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4+ID4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLw0KPiA+PiA+ Pg0KPiA+PiA+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6 DQo+ID4+ID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVy bmJpcy0xNQ0KPiA+PiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtdHJhbS10dXJuYmlzLTE1DQo+ID4+ID4+DQo+ID4+ID4+IEEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTE1DQo+ID4+ID4+ DQo+ID4+ID4+DQo+ID4+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+ID4+IHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCj4gPj4gPj4NCj4gPj4gPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+PiA+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KPiA+PiA+Pg0KPiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+PiA+PiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+PiA+PiB0cmFt QGlldGYub3JnDQo+ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHJhbQ0KPiA+PiA+DQo+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4gPiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+PiA+IHRyYW1AaWV0Zi5v cmcNCj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHRy YW0gbWFpbGluZyBsaXN0DQo+ID4gdHJhbUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0K From nobody Mon Apr 2 09:22:47 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 0F87612D7E4 for ; Mon, 2 Apr 2018 09:22:46 -0700 (PDT) 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 gNF6o3g-bBkb for ; Mon, 2 Apr 2018 09:22:44 -0700 (PDT) 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 44994126CD6 for ; Mon, 2 Apr 2018 09:22:44 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w32GITCB010959; Mon, 2 Apr 2018 17:22:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=PRisiFgJFo3OiVejqZ6bewIJqjbwEiTsktJurHIey4A=; b=KbY4AgFv8VyFceKf4U66vBDHYAA+lumC+7jpQRrbCdTVS0vtvLnUWbNIN3pOt12Gbspn K9YZfN+HwV/9jrOpinyCtolofyo+NmJKbsZ6WzwqdpOiWP01OQZchxOENGsye3HnLNg1 jLju8Lyr8tifOr7lJU9TuxQQtqvK/P1s744FfZBv19v4kFtYpItDXhh3sllZSXMsTEmf Gz0SbGcvaqWoKb8zNeWV5vQa+xYxCBdVFo8x6J+tsGRrC7eEP31WE476vmf91JDlIfvX IYnCfb3QMan0pxj4Z7zZO0uWhPI0b2rQVE/2V/DB8lJNPBsrLGcwqJtkzc7ScxNT+Ssu WQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2h1y6rn5un-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Apr 2018 17:22:40 +0100 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 w32GLYhT025394; Mon, 2 Apr 2018 12:22:40 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2h25nvybg3-1; Mon, 02 Apr 2018 12:22:40 -0400 Received: from [172.28.118.127] (bowill.kendall.corp.akamai.com [172.28.118.127]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id A70FB200E7; Mon, 2 Apr 2018 16:22:39 +0000 (GMT) To: Justin Uberti , Simon Perreault Cc: TirumaleswarReddy_Konda@mcafee.com, Nils Ohlmeier , "Cullen Jennings (fluffy)" , Eric Rescorla , tram@ietf.org References: <8d57a9e5-5697-38f5-1b85-bf55930c6461@akamai.com> From: Brandon Williams Message-ID: <59a6378a-38ac-3168-e93e-d3e395122ae5@akamai.com> Date: Mon, 2 Apr 2018 12:22:38 -0400 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: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-02_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=639 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804020182 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-02_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=619 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804020181 Archived-At: Subject: Re: [tram] Allow TURN to forward inbound connectivity checks without permission 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, 02 Apr 2018 16:22:46 -0000 Agreed. Different networks will require different access controls. Some will be fine with letting anything through. Some will be fine with letting anything through as long as it looks like STUN. And some will want to have the tighter controls they get from existing methods. Providing flexibility with a discussion of the trade-offs seems like the right approach to me too. The ufrag method was intended more to protect the client by giving some control over what's allowed through while opening it up a bit more. Neither that nor checking for STUN framing protects the relay or network from a dedicated user who really wants to create a new service, but both protect against the simplest misuses. --Brandon On 04/01/2018 06:09 PM, Justin Uberti wrote: > > > On Sun, Apr 1, 2018 at 9:56 AM Simon Perreault > wrote: > > 2018-03-31 18:50 GMT-04:00 Justin Uberti >: > > As Brandon says, the ufrag/pwd info could be posted along with > the address of the server, so while this raises the bar, it > doesn't solve the problem. > > I agree with Brandon that the only reasonable way to completely > contain this is some sort of server policy, e.g., some time > window or session count after which the permission bypass > expires, meaning that someone running a server would have to be > continually requesting new allocations and posting their > address/credentials. > > > Do we need to completely contain this? Is there actually a problem > with the proposal? > > Allowing STUN in allows someone to run a server if and only if the > protocol masquerades as STUN. It doesn't allow a user to run an > arbitrary server. For this to be exploitable, the user would also > need to control the clients in some way. > > I can't think of a way this could be exploited practically. Maybe I > lack imagination? > > > I don't think this is fatal to the proposal. I just think that we need > to be up front that this is a potential loophole, and have some explicit > discussion in the document of how one might solve this problem should it > become necessary (e.g., with server policy). From nobody Mon Apr 2 09:46:58 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 290A512D7F2 for ; Mon, 2 Apr 2018 09:46:56 -0700 (PDT) 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 CrH2YmyAYNSu for ; Mon, 2 Apr 2018 09:46:53 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 A3B8812D778 for ; Mon, 2 Apr 2018 09:46:53 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w32GSRkC009013; Mon, 2 Apr 2018 17:46:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=ti15EbTjkNMOAuwRiIqmgPGnvIMBxGwWr1jobx+1S7U=; b=KnuuOy35hKPJOSQxHJ8xlul28UA3UBr0mwunf/ambLLCoAbA43+Uoc/e2E9bEYC6JQnO 4D09aBUqEtRJ+M8SUYq/1u/HmMezbWQ7mnm5vNg6npA7DZZuXmYin19T8LP5seVCrQek PSAmaJxK2QY4aJ9NqtxWt2UK7aqQAdP8tzoW/EKdHAadwxVVdnnZaR5ExsiXFqJ9Aofg ofNgUISgFMK/ssnhLxEWqbmz/NoH61EQQn3Oz+AETIpY07fC5pf84n/nQYeOCHLq9y1D tKDb9/cLd+YAj5+MpP6ewKcamyrK/ugyeznGjrB9IpFww3NJk+xUyYs5Ma5Ri+fiYTLb 6Q== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2h21kmnn6v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Apr 2018 17:46:41 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w32GRK70022168; Mon, 2 Apr 2018 12:46:40 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2h25nwyb43-1; Mon, 02 Apr 2018 12:46:39 -0400 Received: from [172.28.118.127] (bowill.kendall.corp.akamai.com [172.28.118.127]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 1923E200FD; Mon, 2 Apr 2018 16:46:39 +0000 (GMT) To: Karl Stahl , 'Simon Perreault' Cc: "'Konda, Tirumaleswar Reddy'" , "'Olle E. Johansson'" , tram@ietf.org References: <152136260256.18150.10551009018364033510@ietfa.amsl.com> <048b01d3c223$249e62c0$6ddb2840$@stahl@ingate.com> From: Brandon Williams Message-ID: <0e354f75-5ca9-07d2-9e63-2b9bc49fd4fe@akamai.com> Date: Mon, 2 Apr 2018 12:46:38 -0400 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: <048b01d3c223$249e62c0$6ddb2840$@stahl@ingate.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-02_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-1804020183 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-02_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-1804020183 Archived-At: Subject: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.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, 02 Apr 2018 16:46:56 -0000 Karl, There is no WG decision to hinder this, simply a disagreement about approach. Some of us (the editors in particular) have been working on the turnbis draft for quite some time. It went into WGLC several months ago and it is already well behind the originally agreed schedule in the charter. Considering the fact that this is not something that was ever called out previously, we are only questioning why it has suddenly become critical to expand the scope of turnbis and thus delay publishing even further. If there were already a draft that explains the rationale, use cases, and protocol changes, it would be easier to assess the impact and consider inclusion. This was the path followed by a few other new capabilities that were eventually rolled directly into turnbis. If the WG came to the conclusion that we should not delay turnbis any further but instead should advance the capability as a new RFC candidate, we would already be in a good position to that if we had a draft in hand. If the WG decided to include this in turnbis, we would already have text available. IOW, I am only resisting the idea of expanding the scope of turnbis without WG consensus to do so; I am not resisting your proposal itself. The suggestion that you take the time to write down your idea in I-D format seems like a good way for you to drive the required WG discussion. --Brandon On 03/22/2018 05:17 PM, Karl Stahl wrote: > No and this draft cannot be approved without the generalization I have > pointed out. > > I really don’t understand why we are having this resistance. > > Already the second paragraph of the Abstract states: > > 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. > > And further in the Introduction > > TURN was designed as one piece in the larger ICE approach to NAT > >    traversal.  Implementors of TURN are *_urged_* to investigate ICE and > >    seriously consider using it for their application. > > ** > > I cannot imagine that there is some WG decision to hinder ICE usage for > network provided TURN servers EXCEPT FOR EXACTLY BRANDON’S NETWORK. > > For now I refrain from writing/debating more – which would override the > effort of what is required to generalize as asked. > > Please be happy that most of the dual allocation work done, can be > reused to fulfill the generalization. > > Tiru and Brandon are encouraged to read the TRAM charter … > > /Karl > > *Från:*Simon Perreault [mailto:sperreault@jive.com] > *Skickat:* den 21 mars 2018 18:13 > *Till:* Brandon Williams > *Kopia:* Konda, Tirumaleswar Reddy; Olle E. Johansson; Karl Stahl; > tram@ietf.org > *Ämne:* Re: [tram] Multiple allocations SV: I-D Action: > draft-ietf-tram-turnbis-15.txt > > 2018-03-21 17:05 GMT+00:00 Brandon Williams >: > > Chairs, Any suggestions on approach? > > The proposal on the table is for Karl+Olle to write their idea into a > new draft. > > Karl+Olle, can you guys live with that? > > Simon > > ********************** > > Let me explain more clearly why multiple allocations is needed: > > ICE is about finding all/many paths for the media, e.g. with the help of > > TURN servers. > > Those paths are not over ONE IPv4 network, over ONE IPv6 network or EXACTLY > > ONE OF EACH. > > If fact, it is more common that you have several IPv4 networks paths. > > Now that we have network provided TURN servers, you only ask for Allocation > > once (contrary to application provided TURN servers, where you can be > > directed to Allocate several times.) and thus we need all relay addresses in > > one allocation request. > > Wasn't that the reason dual allocation was requested? The need for multiple > > allocation is stronger! > > Please address this, e.g. like below (seems you are almost there). > > /Karl > > ******************* Previous ******************* > > Allowing a turn allocation to return multiple relayed transport addresses, > > beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on different > > interfaces/network segments), seems like very small step now when the dual > > allocation was put in place in this draft. We certainly need it (some > > reasons below) if TURN is going to be used where needed and we cannot wait > > for any additional draft. > > Seems like it is sufficient to extent this table (found in draft 14) with 3 > > new values (as shown): > > 16.  STUN Attributes > >    This STUN extension defines the following attributes: > >      0x000C: CHANNEL-NUMBER > >      0x000D: LIFETIME > >      0x0010: Reserved (was BANDWIDTH) > >      0x0012: XOR-PEER-ADDRESS > >      0x0013: DATA > >      0x0016: XOR-RELAYED-ADDRESS > >      0x0017: REQUESTED-ADDRESS-FAMILY > >      0x0018: EVEN-PORT > >      0x0019: REQUESTED-TRANSPORT > >      0x001A: DONT-FRAGMENT > >      0x0021: Reserved (was TIMER-VAL) > >      0x0022: RESERVATION-TOKEN > >      TBD-CA: ADDITIONAL-ADDRESS-FAMILY > > ADDITIONAL-ADDRESS-ALL > > ADDITIONAL-ADDRESS-ALLV4 > > ADDITIONAL-ADDRESS-ALLV6 > >      TBD-CA: ADDRESS-ERROR-CODE > >      TBD-CA: ICMP > > Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, very > > little text seems to be added for generalization to  ADDITIONAL-ADDRESS-xxx. > > Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be reused. > > ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN client. > > Check! - We need this now. > > Thanks, > > Karl > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Mon Apr 2 11:47:47 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 70F3D1241F8 for ; Mon, 2 Apr 2018 11:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv3-tIGbuV_5 for ; Mon, 2 Apr 2018 11:47:43 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 714EB12D86C for ; Mon, 2 Apr 2018 11:47:38 -0700 (PDT) Received: from [192.168.40.3] (h-205-12.A165.corp.bahnhof.se [176.10.205.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id F2FB0235E; Mon, 2 Apr 2018 20:47:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Olle E. Johansson" In-Reply-To: <0e354f75-5ca9-07d2-9e63-2b9bc49fd4fe@akamai.com> Date: Mon, 2 Apr 2018 20:47:35 +0200 Cc: Olle E Johansson , Karl Stahl , Simon Perreault , "Konda, Tirumaleswar Reddy" , tram@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <708D2731-0E8B-4AB8-B4C1-27C86573341D@edvina.net> References: <152136260256.18150.10551009018364033510@ietfa.amsl.com> <048b01d3c223$249e62c0$6ddb2840$@stahl@ingate.com> <0e354f75-5ca9-07d2-9e63-2b9bc49fd4fe@akamai.com> To: Brandon Williams X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.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, 02 Apr 2018 18:47:46 -0000 Hi! Well, since Network-provided servers was added to the security section = of RFC 8155, I kind of think it=E2=80=99s now in scope for everything TURN and from that standpoint I do understand Karl=E2=80=99s = objections. On the other hand, I don=E2=80=99t really like how it was added to that = RFC and like the idea of a separate document that clears this mess up and explains clearly how network-provided = TURN-servers is supposed to work, the requirements and additions to the TURN protocol.=20 The problem with that is that implementors may think it=E2=80=99s just = an add-on and not implement it in the TURN client implementations, which would be harmful in the long run.=20 Question: Will adding operations or modifying existing ones in a new = document make it a mandatory part of the TURN protocol, an update to the TURN RFC (turnbis as an RFC = that is)? /O > On 2 Apr 2018, at 18:46, Brandon Williams = wrote: >=20 > Karl, >=20 > There is no WG decision to hinder this, simply a disagreement about = approach. >=20 > Some of us (the editors in particular) have been working on the = turnbis draft for quite some time. It went into WGLC several months ago = and it is already well behind the originally agreed schedule in the = charter. >=20 > Considering the fact that this is not something that was ever called = out previously, we are only questioning why it has suddenly become = critical to expand the scope of turnbis and thus delay publishing even = further. >=20 > If there were already a draft that explains the rationale, use cases, = and protocol changes, it would be easier to assess the impact and = consider inclusion. This was the path followed by a few other new = capabilities that were eventually rolled directly into turnbis. >=20 > If the WG came to the conclusion that we should not delay turnbis any = further but instead should advance the capability as a new RFC = candidate, we would already be in a good position to that if we had a = draft in hand. If the WG decided to include this in turnbis, we would = already have text available. >=20 > IOW, I am only resisting the idea of expanding the scope of turnbis = without WG consensus to do so; I am not resisting your proposal itself. = The suggestion that you take the time to write down your idea in I-D = format seems like a good way for you to drive the required WG = discussion. >=20 > --Brandon >=20 > On 03/22/2018 05:17 PM, Karl Stahl wrote: >> No and this draft cannot be approved without the generalization I = have pointed out. >> I really don=E2=80=99t understand why we are having this resistance. >> Already the second paragraph of the Abstract states: >> 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. >> And further in the Introduction >> TURN was designed as one piece in the larger ICE approach to NAT >> traversal. Implementors of TURN are *_urged_* to investigate ICE = and >> seriously consider using it for their application. >> ** >> I cannot imagine that there is some WG decision to hinder ICE usage = for network provided TURN servers EXCEPT FOR EXACTLY BRANDON=E2=80=99S = NETWORK. >> For now I refrain from writing/debating more =E2=80=93 which would = override the effort of what is required to generalize as asked. >> Please be happy that most of the dual allocation work done, can be = reused to fulfill the generalization. >> Tiru and Brandon are encouraged to read the TRAM charter =E2=80=A6 >> /Karl >> *Fr=C3=A5n:*Simon Perreault [mailto:sperreault@jive.com] >> *Skickat:* den 21 mars 2018 18:13 >> *Till:* Brandon Williams >> *Kopia:* Konda, Tirumaleswar Reddy; Olle E. Johansson; Karl Stahl; = tram@ietf.org >> *=C3=84mne:* Re: [tram] Multiple allocations SV: I-D Action: = draft-ietf-tram-turnbis-15.txt >> 2018-03-21 17:05 GMT+00:00 Brandon Williams = >: >> Chairs, Any suggestions on approach? >> The proposal on the table is for Karl+Olle to write their idea into a = new draft. >> Karl+Olle, can you guys live with that? >> Simon >> ********************** >> Let me explain more clearly why multiple allocations is needed: >> ICE is about finding all/many paths for the media, e.g. with the help = of >> TURN servers. >> Those paths are not over ONE IPv4 network, over ONE IPv6 network or = EXACTLY >> ONE OF EACH. >> If fact, it is more common that you have several IPv4 networks paths. >> Now that we have network provided TURN servers, you only ask for = Allocation >> once (contrary to application provided TURN servers, where you can be >> directed to Allocate several times.) and thus we need all relay = addresses in >> one allocation request. >> Wasn't that the reason dual allocation was requested? The need for = multiple >> allocation is stronger! >> Please address this, e.g. like below (seems you are almost there). >> /Karl >> ******************* Previous ******************* >> Allowing a turn allocation to return multiple relayed transport = addresses, >> beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on = different >> interfaces/network segments), seems like very small step now when the = dual >> allocation was put in place in this draft. We certainly need it (some >> reasons below) if TURN is going to be used where needed and we cannot = wait >> for any additional draft. >> Seems like it is sufficient to extent this table (found in draft 14) = with 3 >> new values (as shown): >> 16. STUN Attributes >> This STUN extension defines the following attributes: >> 0x000C: CHANNEL-NUMBER >> 0x000D: LIFETIME >> 0x0010: Reserved (was BANDWIDTH) >> 0x0012: XOR-PEER-ADDRESS >> 0x0013: DATA >> 0x0016: XOR-RELAYED-ADDRESS >> 0x0017: REQUESTED-ADDRESS-FAMILY >> 0x0018: EVEN-PORT >> 0x0019: REQUESTED-TRANSPORT >> 0x001A: DONT-FRAGMENT >> 0x0021: Reserved (was TIMER-VAL) >> 0x0022: RESERVATION-TOKEN >> TBD-CA: ADDITIONAL-ADDRESS-FAMILY >> ADDITIONAL-ADDRESS-ALL >> ADDITIONAL-ADDRESS-ALLV4 >> ADDITIONAL-ADDRESS-ALLV6 >> TBD-CA: ADDRESS-ERROR-CODE >> TBD-CA: ICMP >> Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, = very >> little text seems to be added for generalization to = ADDITIONAL-ADDRESS-xxx. >> Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be = reused. >> ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN = client. >> Check! - We need this now. >> Thanks, >> Karl >=20 > --=20 > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Apr 2 15:59:58 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 35FF11252BA; Mon, 2 Apr 2018 15:59:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Saint-Andre To: Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152270998513.17947.16209089088681034529@ietfa.amsl.com> Date: Mon, 02 Apr 2018 15:59:45 -0700 Archived-At: Subject: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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, 02 Apr 2018 22:59:45 -0000 Reviewer: Peter Saint-Andre Review result: Ready with Nits Section 1 states: Implementations and deployments of a STUN usage using TLS or DTLS should follow the recommendations in [RFC7525]. Wouldn't the security considerations be a better location for that text? And given that this specification cites RFC 8174, I suggest changing "should" to "SHOULD". (I suggest that the authors review the usage of lowercase and uppercase requirements keywords, because there might be inconsistencies, e.g., in the first paragraphs of Section 6.1 and Section 6.2.) In Section 4, please consider spelling out "SIP" on first use and including a reference to RFC 3261. The first paragaraph of Section 6.2.3 restates recommendations from RFC 7525; why not simply reference that specification? Section 6.3.4 states: o If the error code is 500 through 599, the client MAY resend the request; clients that do so MUST limit the number of times they do this. It is reasonable to provide guidance as to the number of re-sends? Section 9.1.1 and other sections invoke the OpaqueString profile of the PRECIS FreeformClass; it might be helpful to mention that the profile is used to handle Unicode characters outside the ASCII range, and that no changes result if only ASCII characters are used. In Section 14.2, please consider spelling out "ALG" on first use. A reference to RFC 6151 seems appropriate regarding the fact that this specification retains the use of MD5; in particular, the usage here is actually HMAC-MD5, which is still sanctioned by RFC 6151. From nobody Mon Apr 2 22:03: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 A770712DA50 for ; Mon, 2 Apr 2018 22:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 pVgbN6m7-qkt for ; Mon, 2 Apr 2018 22:03:15 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 B80B912D86D for ; Mon, 2 Apr 2018 22:03:14 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id q12so10234756uae.4 for ; Mon, 02 Apr 2018 22:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MXdWPC/LHIBqLopsHwEQluAt8V1o7zCqdlFtupURGu4=; b=dPju9PKIZWI3xD76m3zLD/2XizXsC7a75KF6q7Ga4kqGcxvc1/OB+jWrOD7txy0LtH /IASXuAyzROhi2nrdl5t4dRNd7UD78Up7aZI8hcJZStYwzMK5LjjuPiEVQgoIy6C58Qm lRwNeCEDD2cgHjRrO1k7GjRiL20W/uQerMSg6VKkkd3jWSKOSoZPw8amh1cutWu2sBdb ERtBtJY94yraGhTTkz58+E4Uk1WvCkpzlbMHjwtJddDIyR3tJ/18t4D6JX4pjXBsm3rV YaySQ4HfEbI1KOiWuJziTdSmYRP4rMteWauAs+7CHr9xam1BWKKeYJF/Tbo5xuKg95b6 DhcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MXdWPC/LHIBqLopsHwEQluAt8V1o7zCqdlFtupURGu4=; b=aCNiS25JDmovPxdoyXeancjHV8RwjZTC2/ZfCwz4mMrWTkiGr8yZjEzoIJV2v1+Nrk SFXxlsqCmrDy28+UTpBACeVVBsM61blWMy4qLrL200sO6vFwJSP/alpeGjUdjuxMW69j WXeMTPKNdjkNG1CXmHWTeGMQt51BDtw7Fs2dFxQdxz1vgcjYDoQTt50s70Mr95HGJUMU K0AaUyQZYecp0ZzkahN/gGe8RzCi0RhGmpaEhvRIQhssVlG0e9+OmEZmZQZV5Bo/D7MK j96cSY1INic9Vf9s4ybHjiXz8sj2NOsJXnMP98vL1irWRAEJIMYVe8UcBQqNVjd5LK1C 4rOA== X-Gm-Message-State: ALQs6tC2JxenafTkZL8cM6+Ly4BZLqc1Op8NkBdJcEyGqzKjgQDNZYee p9iqhbizZ2qxBsSvy1t9DWZY98zTS2VvC10ZQtHDsg== X-Google-Smtp-Source: AIpwx49A4YQqZ8YdNpoGOQbr4YEodUyqhCVxSoBnZR2DhQLuwXexEX7p6IsuJVJYUXiQfUlGfmn34UTWwn+QTqUZblo= X-Received: by 10.176.30.136 with SMTP id o8mr541053uak.108.1522731793297; Mon, 02 Apr 2018 22:03:13 -0700 (PDT) MIME-Version: 1.0 References: <152136260256.18150.10551009018364033510@ietfa.amsl.com> <0e354f75-5ca9-07d2-9e63-2b9bc49fd4fe@akamai.com> <708D2731-0E8B-4AB8-B4C1-27C86573341D@edvina.net> In-Reply-To: <708D2731-0E8B-4AB8-B4C1-27C86573341D@edvina.net> From: Justin Uberti Date: Tue, 03 Apr 2018 05:03:02 +0000 Message-ID: To: "Olle E. Johansson" Cc: Brandon Williams , Simon Perreault , TirumaleswarReddy_Konda@mcafee.com, tram@ietf.org, Karl Stahl Content-Type: multipart/alternative; boundary="089e0828e490a1664f0568ea9f67" Archived-At: Subject: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.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: Tue, 03 Apr 2018 05:03:20 -0000 --089e0828e490a1664f0568ea9f67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I spent time with Pal and others coming up with the initial dual allocation concept (SSODA) and there are clear reasons for this approach (as discussed in the intro of the original SSODA doc). It's not clear to me why multiple addresses of the same family are ever needed though, and even if we supported this, how the client would be expected to select between them. It seems like a large expansion of scope beyond the goals of SSODA. On Mon, Apr 2, 2018 at 11:47 AM Olle E. Johansson wrote: > Hi! > > Well, since Network-provided servers was added to the security section of > RFC 8155, I kind of think it=E2=80=99s now in scope for > everything TURN and from that standpoint I do understand Karl=E2=80=99s o= bjections. > > On the other hand, I don=E2=80=99t really like how it was added to that R= FC and > like the idea of a separate document that > clears this mess up and explains clearly how network-provided TURN-server= s > is supposed to work, the requirements > and additions to the TURN protocol. > > The problem with that is that implementors may think it=E2=80=99s just an= add-on > and not implement it in the TURN client > implementations, which would be harmful in the long run. > > Question: Will adding operations or modifying existing ones in a new > document make it a mandatory > part of the TURN protocol, an update to the TURN RFC (turnbis as an RFC > that is)? > > /O > > > > > > On 2 Apr 2018, at 18:46, Brandon Williams > wrote: > > > > Karl, > > > > There is no WG decision to hinder this, simply a disagreement about > approach. > > > > Some of us (the editors in particular) have been working on the turnbis > draft for quite some time. It went into WGLC several months ago and it is > already well behind the originally agreed schedule in the charter. > > > > Considering the fact that this is not something that was ever called ou= t > previously, we are only questioning why it has suddenly become critical t= o > expand the scope of turnbis and thus delay publishing even further. > > > > If there were already a draft that explains the rationale, use cases, > and protocol changes, it would be easier to assess the impact and conside= r > inclusion. This was the path followed by a few other new capabilities tha= t > were eventually rolled directly into turnbis. > > > > If the WG came to the conclusion that we should not delay turnbis any > further but instead should advance the capability as a new RFC candidate, > we would already be in a good position to that if we had a draft in hand. > If the WG decided to include this in turnbis, we would already have text > available. > > > > IOW, I am only resisting the idea of expanding the scope of turnbis > without WG consensus to do so; I am not resisting your proposal itself. T= he > suggestion that you take the time to write down your idea in I-D format > seems like a good way for you to drive the required WG discussion. > > > > --Brandon > > > > On 03/22/2018 05:17 PM, Karl Stahl wrote: > >> No and this draft cannot be approved without the generalization I have > pointed out. > >> I really don=E2=80=99t understand why we are having this resistance. > >> Already the second paragraph of the Abstract states: > >> 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. > >> And further in the Introduction > >> TURN was designed as one piece in the larger ICE approach to NAT > >> traversal. Implementors of TURN are *_urged_* to investigate ICE a= nd > >> seriously consider using it for their application. > >> ** > >> I cannot imagine that there is some WG decision to hinder ICE usage fo= r > network provided TURN servers EXCEPT FOR EXACTLY BRANDON=E2=80=99S NETWOR= K. > >> For now I refrain from writing/debating more =E2=80=93 which would ove= rride the > effort of what is required to generalize as asked. > >> Please be happy that most of the dual allocation work done, can be > reused to fulfill the generalization. > >> Tiru and Brandon are encouraged to read the TRAM charter =E2=80=A6 > >> /Karl > >> *Fr=C3=A5n:*Simon Perreault [mailto:sperreault@jive.com] > >> *Skickat:* den 21 mars 2018 18:13 > >> *Till:* Brandon Williams > >> *Kopia:* Konda, Tirumaleswar Reddy; Olle E. Johansson; Karl Stahl; > tram@ietf.org > >> *=C3=84mne:* Re: [tram] Multiple allocations SV: I-D Action: > draft-ietf-tram-turnbis-15.txt > >> 2018-03-21 17:05 GMT+00:00 Brandon Williams < > brandon.williams@akamai.com >: > >> Chairs, Any suggestions on approach? > >> The proposal on the table is for Karl+Olle to write their idea into a > new draft. > >> Karl+Olle, can you guys live with that? > >> Simon > >> ********************** > >> Let me explain more clearly why multiple allocations is needed: > >> ICE is about finding all/many paths for the media, e.g. with the help = of > >> TURN servers. > >> Those paths are not over ONE IPv4 network, over ONE IPv6 network or > EXACTLY > >> ONE OF EACH. > >> If fact, it is more common that you have several IPv4 networks paths. > >> Now that we have network provided TURN servers, you only ask for > Allocation > >> once (contrary to application provided TURN servers, where you can be > >> directed to Allocate several times.) and thus we need all relay > addresses in > >> one allocation request. > >> Wasn't that the reason dual allocation was requested? The need for > multiple > >> allocation is stronger! > >> Please address this, e.g. like below (seems you are almost there). > >> /Karl > >> ******************* Previous ******************* > >> Allowing a turn allocation to return multiple relayed transport > addresses, > >> beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on differen= t > >> interfaces/network segments), seems like very small step now when the > dual > >> allocation was put in place in this draft. We certainly need it (some > >> reasons below) if TURN is going to be used where needed and we cannot > wait > >> for any additional draft. > >> Seems like it is sufficient to extent this table (found in draft 14) > with 3 > >> new values (as shown): > >> 16. STUN Attributes > >> This STUN extension defines the following attributes: > >> 0x000C: CHANNEL-NUMBER > >> 0x000D: LIFETIME > >> 0x0010: Reserved (was BANDWIDTH) > >> 0x0012: XOR-PEER-ADDRESS > >> 0x0013: DATA > >> 0x0016: XOR-RELAYED-ADDRESS > >> 0x0017: REQUESTED-ADDRESS-FAMILY > >> 0x0018: EVEN-PORT > >> 0x0019: REQUESTED-TRANSPORT > >> 0x001A: DONT-FRAGMENT > >> 0x0021: Reserved (was TIMER-VAL) > >> 0x0022: RESERVATION-TOKEN > >> TBD-CA: ADDITIONAL-ADDRESS-FAMILY > >> ADDITIONAL-ADDRESS-ALL > >> ADDITIONAL-ADDRESS-ALLV4 > >> ADDITIONAL-ADDRESS-ALLV6 > >> TBD-CA: ADDRESS-ERROR-CODE > >> TBD-CA: ICMP > >> Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, ve= ry > >> little text seems to be added for generalization to > ADDITIONAL-ADDRESS-xxx. > >> Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be reused. > >> ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN clien= t. > >> Check! - We need this now. > >> Thanks, > >> Karl > > > > -- > > Brandon Williams; Chief Architect > > Cloud Networking; Akamai Technologies Inc. > > > > _______________________________________________ > > 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 > --089e0828e490a1664f0568ea9f67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I spent time with Pal and others coming up with the initia= l dual allocation concept (SSODA) and there are clear reasons for this appr= oach (as discussed in the intro of the original SSODA doc).

<= div>It's not clear to me why multiple addresses of the same family are = ever needed though, and even if we supported this, how the client would be = expected to select between them. It seems like a large expansion of scope b= eyond the goals of SSODA.

On Mon, Apr 2, 2018 at 11:47 AM Olle E. Johansson <oej@edvina.net> wrote:
Hi!

Well, since Network-provided servers was added to the security section of R= FC 8155, I kind of think it=E2=80=99s now in scope for
everything TURN and from that standpoint I do understand Karl=E2=80=99s obj= ections.

On the other hand, I don=E2=80=99t really like how it was added to that RFC= and like the idea of a separate document that
clears this mess up and explains clearly how network-provided TURN-servers = is supposed to work, the requirements
and additions to the TURN protocol.

The problem with that is that implementors may think it=E2=80=99s just an a= dd-on and not implement it in the TURN client
implementations, which would be harmful in the long run.

Question: Will adding operations or modifying existing ones in a new docume= nt make it a mandatory
part of the TURN protocol, an update to the TURN RFC (turnbis as an RFC tha= t is)?

/O




> On 2 Apr 2018, at 18:46, Brandon Williams <brandon.williams@akamai.com>= ; wrote:
>
> Karl,
>
> There is no WG decision to hinder this, simply a disagreement about ap= proach.
>
> Some of us (the editors in particular) have been working on the turnbi= s draft for quite some time. It went into WGLC several months ago and it is= already well behind the originally agreed schedule in the charter.
>
> Considering the fact that this is not something that was ever called o= ut previously, we are only questioning why it has suddenly become critical = to expand the scope of turnbis and thus delay publishing even further.
>
> If there were already a draft that explains the rationale, use cases, = and protocol changes, it would be easier to assess the impact and consider = inclusion. This was the path followed by a few other new capabilities that = were eventually rolled directly into turnbis.
>
> If the WG came to the conclusion that we should not delay turnbis any = further but instead should advance the capability as a new RFC candidate, w= e would already be in a good position to that if we had a draft in hand. If= the WG decided to include this in turnbis, we would already have text avai= lable.
>
> IOW, I am only resisting the idea of expanding the scope of turnbis wi= thout WG consensus to do so; I am not resisting your proposal itself. The s= uggestion that you take the time to write down your idea in I-D format seem= s like a good way for you to drive the required WG discussion.
>
> --Brandon
>
> On 03/22/2018 05:17 PM, Karl Stahl wrote:
>> No and this draft cannot be approved without the generalization I = have pointed out.
>> I really don=E2=80=99t understand why we are having this resistanc= e.
>> Already the second paragraph of the Abstract states:
>> The TURN protocol was designed to be used as part of the ICE
>>=C2=A0 =C2=A0 (Interactive Connectivity Establishment) approach to = NAT traversal,
>>=C2=A0 =C2=A0 though it also can be used without ICE.
>> And further in the Introduction
>> TURN was designed as one piece in the larger ICE approach to NAT >>=C2=A0 =C2=A0 traversal.=C2=A0 Implementors of TURN are *_urged_* t= o investigate ICE and
>>=C2=A0 =C2=A0 seriously consider using it for their application. >> **
>> I cannot imagine that there is some WG decision to hinder ICE usag= e for network provided TURN servers EXCEPT FOR EXACTLY BRANDON=E2=80=99S NE= TWORK.
>> For now I refrain from writing/debating more =E2=80=93 which would= override the effort of what is required to generalize as asked.
>> Please be happy that most of the dual allocation work done, can be= reused to fulfill the generalization.
>> Tiru and Brandon are encouraged to read the TRAM charter =E2=80=A6=
>> /Karl
>> *Fr=C3=A5n:*Simon Perreault [mailto:sperreault@jive.com]
>> *Skickat:* den 21 mars 2018 18:13
>> *Till:* Brandon Williams
>> *Kopia:* Konda, Tirumaleswar Reddy; Olle E. Johansson; Karl Stahl;= tram@ietf.org
>> *=C3=84mne:* Re: [tram] Multiple allocations SV: I-D Action: draft= -ietf-tram-turnbis-15.txt
>> 2018-03-21 17:05 GMT+00:00 Brandon Williams <brandon.williams@akamai.com<= /a> <mailto:brandon.williams@akamai.com>>:
>> Chairs, Any suggestions on approach?
>> The proposal on the table is for Karl+Olle to write their idea int= o a new draft.
>> Karl+Olle, can you guys live with that?
>> Simon
>> **********************
>> Let me explain more clearly why multiple allocations is needed: >> ICE is about finding all/many paths for the media, e.g. with the h= elp of
>> TURN servers.
>> Those paths are not over ONE IPv4 network, over ONE IPv6 network o= r EXACTLY
>> ONE OF EACH.
>> If fact, it is more common that you have several IPv4 networks pat= hs.
>> Now that we have network provided TURN servers, you only ask for A= llocation
>> once (contrary to application provided TURN servers, where you can= be
>> directed to Allocate several times.) and thus we need all relay ad= dresses in
>> one allocation request.
>> Wasn't that the reason dual allocation was requested? The need= for multiple
>> allocation is stronger!
>> Please address this, e.g. like below (seems you are almost there).=
>> /Karl
>> ******************* Previous *******************
>> Allowing a turn allocation to return multiple relayed transport ad= dresses,
>> beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on diff= erent
>> interfaces/network segments), seems like very small step now when = the dual
>> allocation was put in place in this draft. We certainly need it (s= ome
>> reasons below) if TURN is going to be used where needed and we can= not wait
>> for any additional draft.
>> Seems like it is sufficient to extent this table (found in draft 1= 4) with 3
>> new values (as shown):
>> 16.=C2=A0 STUN Attributes
>>=C2=A0 =C2=A0 This STUN extension defines the following attributes:=
>>=C2=A0 =C2=A0 =C2=A0 0x000C: CHANNEL-NUMBER
>>=C2=A0 =C2=A0 =C2=A0 0x000D: LIFETIME
>>=C2=A0 =C2=A0 =C2=A0 0x0010: Reserved (was BANDWIDTH)
>>=C2=A0 =C2=A0 =C2=A0 0x0012: XOR-PEER-ADDRESS
>>=C2=A0 =C2=A0 =C2=A0 0x0013: DATA
>>=C2=A0 =C2=A0 =C2=A0 0x0016: XOR-RELAYED-ADDRESS
>>=C2=A0 =C2=A0 =C2=A0 0x0017: REQUESTED-ADDRESS-FAMILY
>>=C2=A0 =C2=A0 =C2=A0 0x0018: EVEN-PORT
>>=C2=A0 =C2=A0 =C2=A0 0x0019: REQUESTED-TRANSPORT
>>=C2=A0 =C2=A0 =C2=A0 0x001A: DONT-FRAGMENT
>>=C2=A0 =C2=A0 =C2=A0 0x0021: Reserved (was TIMER-VAL)
>>=C2=A0 =C2=A0 =C2=A0 0x0022: RESERVATION-TOKEN
>>=C2=A0 =C2=A0 =C2=A0 TBD-CA: ADDITIONAL-ADDRESS-FAMILY
>> ADDITIONAL-ADDRESS-ALL
>> ADDITIONAL-ADDRESS-ALLV4
>> ADDITIONAL-ADDRESS-ALLV6
>>=C2=A0 =C2=A0 =C2=A0 TBD-CA: ADDRESS-ERROR-CODE
>>=C2=A0 =C2=A0 =C2=A0 TBD-CA: ICMP
>> Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY= , very
>> little text seems to be added for generalization to=C2=A0 ADDITION= AL-ADDRESS-xxx.
>> Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be reu= sed.
>> ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN c= lient.
>> Check! - We need this now.
>> Thanks,
>> Karl
>
> --
> Brandon Williams; Chief Architect
> Cloud Networking; Akamai Technologies Inc.
>
> _______________________________________________
> 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
--089e0828e490a1664f0568ea9f67-- From nobody Wed Apr 4 20:28:41 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 33C83127076 for ; Wed, 4 Apr 2018 20:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 VNRdRo9RG5Jf for ; Wed, 4 Apr 2018 20:28:37 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 6C937126B6D for ; Wed, 4 Apr 2018 20:28:37 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id 126-v6so21275677oig.0 for ; Wed, 04 Apr 2018 20:28:37 -0700 (PDT) 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 :content-transfer-encoding; bh=MjniwzJZdn6eUReq+Ru9/7H5y9oLXFG8AUStjcdijOY=; b=jvYoP+gzTulEYF2f9MrR9WfjaSlbFJ/gb7EJVHd0B3Gp0QJdA4t0wT6xkHSF/F/IzD g+skVXN1OiO+CY6ohNkgcgahAtKP/bRi90Zgcv/sSmd2+4dt1rJv2ORJxaGtj4yjkTAv EhN7yotPAJVJ01hxuWG64jwoaBaIWsWgxNl1rztycoRU/eiovO5rOJYkbw+L3qnYCvcw wpLRSful2/6FdyWsOakO+EICVWlH/dbqYNVkVSQUF7mW3lngT/l0K4FFJFKGcBm1gheA 3CGERt5yUp/2VLh1gxOuE0gH95YB/iQrFw/3x1NPdblQTfx+HA91AzGG+mjtmxztrGXS fzag== 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:content-transfer-encoding; bh=MjniwzJZdn6eUReq+Ru9/7H5y9oLXFG8AUStjcdijOY=; b=EUF89gLljSOR/brgcuRMsZPvdxBx7aWFatzKDyCDIg9o3+rShfK94v+MJv3FnMdk3n scZUK3g4n8gEqY4NhugglCC2vKWooyDV1fI86eWV8BjoHuVNthouROdk/v9/FgjTt5bH RqVNUdKxM4QbhwLFw1gZTzbAl5AWKkAPZ0Su2RT4OyuRwPtl30rxql83/Ehz+rPWJVa6 D9yye1RgzUOB1stlnpXF0liz1IEYBJtmkZ+oFFqIA2Bu5SpPhuDXYFrYxohl0NeQLFHl zXVf9hO9dzQ3f4eQpgFjVQR3cvnhNoj4q4u2stKkFzj+EbdMOMtrj+gH6axBHmydhB5u sBRQ== X-Gm-Message-State: ALQs6tCz/5/BiUkTNZuit8xTIhD8mQDhII/mhVnnIBZ44FucXZNfbcE2 vLOF++pdr7uLJtKhukZkVMzAWB1PpySfKcqg4wCErTxF X-Google-Smtp-Source: AIpwx48y8objamcUru8hO3SrCk+zn0KGnsR14xxgrlsNtjLvFnucA2xYAVByHuSE3gZ4gZmurkaj5curCFx+xLu1CvU= X-Received: by 2002:aca:34c2:: with SMTP id b185-v6mr12195624oia.244.1522898916604; Wed, 04 Apr 2018 20:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.115.209 with HTTP; Wed, 4 Apr 2018 20:28:36 -0700 (PDT) In-Reply-To: <5ab16736.d461ca0a.4c075.ef7dSMTPIN_ADDED_BROKEN@mx.google.com> References: <152136260256.18150.10551009018364033510@ietfa.amsl.com> <5ab16736.d461ca0a.4c075.ef7dSMTPIN_ADDED_BROKEN@mx.google.com> From: Noriyuki Torii Date: Thu, 5 Apr 2018 12:28:36 +0900 Message-ID: To: tram@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.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, 05 Apr 2018 03:28:40 -0000 Hi, >From my understandings, current TURNbis specification is intended, as its scope of, just a single IP addressed server nevertheless its IPv4/v6 co-allocation capability. Such a capablity is introduced for v4 <-> v6 communication, and not as a generalization for a multiple IP addressed server. IMHO, if a server with multiple IP addresses of the same family will be deployed into service, idential form of allocation request currently defined also should be sent to such a server. And the server must process the request appropriately according to its network configuration. In general, clients don't know, and shouldn't need to know, how many IP addresses are given to the server communicating with, or how is the topology of the network into where the server is deployed, etc. So the client side request form selection is not usually possible. Because of above, I'm afraid to say but I couldn't agree with the Karl's proposal of the modification of request form with additional attributes, although I can understand there exists the demand of specification for multiple IP addressed server. I think the generalization of TURN for multiple IP addressed server is something need more discussion and separate publication. Regards, Noriyuki Torii 2018-03-21 4:55 GMT+09:00 Karl Stahl : >> This revision addresses comments from Mark, Karl and Noriyuki Torii. > My comment about need for multiple allocations is NOT addressed. > > Let me explain more clearly why multiple allocations is needed: > > ICE is about finding all/many paths for the media, e.g. with the help of > TURN servers. > Those paths are not over ONE IPv4 network, over ONE IPv6 network or EXACT= LY > ONE OF EACH. > If fact, it is more common that you have several IPv4 networks paths. > > Now that we have network provided TURN servers, you only ask for Allocati= on > once (contrary to application provided TURN servers, where you can be > directed to Allocate several times.) and thus we need all relay addresses= in > one allocation request. > > Wasn't that the reason dual allocation was requested? The need for multip= le > allocation is stronger! > > Please address this, e.g. like below (seems you are almost there). > > /Karl > > > ******************* Previous ******************* > > Allowing a turn allocation to return multiple relayed transport addresses= , > beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on different > interfaces/network segments), seems like very small step now when the dua= l > allocation was put in place in this draft. We certainly need it (some > reasons below) if TURN is going to be used where needed and we cannot wai= t > for any additional draft. > > Seems like it is sufficient to extent this table (found in draft 14) with= 3 > new values (as shown): > > 16. STUN Attributes > > This STUN extension defines the following attributes: > > 0x000C: CHANNEL-NUMBER > 0x000D: LIFETIME > 0x0010: Reserved (was BANDWIDTH) > 0x0012: XOR-PEER-ADDRESS > 0x0013: DATA > 0x0016: XOR-RELAYED-ADDRESS > 0x0017: REQUESTED-ADDRESS-FAMILY > 0x0018: EVEN-PORT > 0x0019: REQUESTED-TRANSPORT > 0x001A: DONT-FRAGMENT > 0x0021: Reserved (was TIMER-VAL) > 0x0022: RESERVATION-TOKEN > TBD-CA: ADDITIONAL-ADDRESS-FAMILY > ADDITIONAL-ADDRESS-ALL > ADDITIONAL-ADDRESS-ALLV4 > ADDITIONAL-ADDRESS-ALLV6 > TBD-CA: ADDRESS-ERROR-CODE > TBD-CA: ICMP > > Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, very > little text seems to be added for generalization to ADDITIONAL-ADDRESS-x= xx. > Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be reused. > > ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN client. > > Check! - We need this now. > > Thanks, > Karl > >> -----Original Message----- >> From: Karl Stahl [mailto:karl.stahl@ingate.com] >> Sent: Sunday, March 4, 2018 10:36 PM >> To: 'Marc Petit-Huguenin' ; Konda, Tirumaleswar Reddy >> ; tram@ietf.org >> Subject: SV: [tram] Review of dual allocation in TURNbis-11 >> >> Hi, >> >> When we now have "dual allocation" into this draft (I see on page 26: "I= f > the >> client wishes to obtain one IPv6 and one IPv4 relayed transport address > then >> it includes an ADDITIONAL-ADDRESS-FAMILY transport address then it") can >> we not generalize that further and allow MORE THAN ONE relayed transport >> address (of any family) in response to an allocation? >> >> I mean that a TURN server could have several relay interfaces at differe= nt > IP- >> addresses into different networks - not just the Internet, but also a Vo= IP >> (higher quality) network e.g. by some triple play service provider, an I= MS >> network or some branch office network. >> >> I think this is specifically important for network provided/auto > discovered >> turn servers (application provided turn servers could instead just list > several >> turn servers). >> >> I saw someone snipped this about "SINGLE relayed transport address per >> allocation request" >> > > https://tools.ietf.org/html/rfc6156#section-3 >> > > >> > > >> > > TURN servers allocate a single relayed transport address per >> > > allocation request. Therefore, Allocate requests cannot carry mo= re >> > > than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a >> client >> > > that wishes to allocate more than one relayed transport address a= t > a >> > > TURN server (e.g., an IPv4 and an IPv6 address) needs to perform >> > > several allocation requests (one allocation request per relayed >> > > transport address). >> > > >> >> but if that is remedied now, it seems like a small step to generalize so > we can >> get multiple relayed transport addresses from one allocate request? >> >> /Karl > > > -----Ursprungligt meddelande----- > Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Konda, Tirumalesw= ar Reddy > Skickat: den 18 mars 2018 09:51 > Till: tram@ietf.org > =C3=84mne: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt > > This revision addresses comments from Mark, Karl and Noriyuki Torii. > > -Tiru > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Sunday, March 18, 2018 8:43 AM >> To: i-d-announce@ietf.org >> Cc: tram@ietf.org >> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-15.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): Rela= y > Extensions >> to Session Traversal Utilities for NAT (STUN) >> Authors : Tirumaleswar Reddy >> Alan Johnston >> Philip Matthews >> Jonathan Rosenberg >> Filename : draft-ietf-tram-turnbis-15.txt >> Pages : 84 >> Date : 2018-03-18 >> >> 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-15 >> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-15 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-15 >> >> >> 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 > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Apr 5 08:52:48 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 109AB12D88D for ; Thu, 5 Apr 2018 08:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 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, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ingate.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 E246GuWZnp1t for ; Thu, 5 Apr 2018 08:52:43 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0079.outbound.protection.outlook.com [104.47.0.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632AE12D87D for ; Thu, 5 Apr 2018 08:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ingate.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NjjYJOnz2wSrKaWQiRE3ejnN3SgYnsH44Rvbi9haSmw=; b=F5SAnjlsui5OAydU6T1qje+c6xRR0ti9hTnktThex0Jnli5SUqqnBIZH3DdMtF233xMJYaIAb0vYDccOEwfiJ7mXCoQBbtavXRZaXy6TD8hagCNJmo1uoycihkwEeltH3J/Rlqss9HkurIJ1/v2hRnVJEYeI1na8+GJ4ZVutdb0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=karl@ingate.com; Received: from Kallei7 (90.229.133.175) by AM4PR01MB1825.eurprd01.prod.exchangelabs.com (2603:10a6:200:9::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Thu, 5 Apr 2018 15:52:37 +0000 From: "Karl Stahl" To: "'Noriyuki Torii'" , References: <152136260256.18150.10551009018364033510@ietfa.amsl.com> <5ab16736.d461ca0a.4c075.ef7dSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 5 Apr 2018 17:52:43 +0200 Message-ID: <01b101d3ccf6$231e5d50$695b17f0$@stahl@ingate.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B2_01D3CD06.E6A72D50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdPMjjRf33GSGjOETYeZjDpy/qpGHwANGn+g Content-Language: sv X-Originating-IP: [90.229.133.175] X-ClientProxiedBy: AM0PR06CA0063.eurprd06.prod.outlook.com (2603:10a6:208:aa::40) To AM4PR01MB1825.eurprd01.prod.exchangelabs.com (2603:10a6:200:9::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fe942a94-4aa5-4d14-1986-08d59b0d4155 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:AM4PR01MB1825; X-Microsoft-Exchange-Diagnostics: 1; AM4PR01MB1825; 3:Ufv3tHpytC9UuM7UIZFv3lGJqZ24txje8764jw4wOEIc9svfCyYupZ20FhPwrNhfnyxlUtg0KWAcnyUAOYsrljQX8zv3Jf1zdr4Hia+DyOyWWRBCKtREEeBMLc09iWA43OlcAIL9M23+rSR802Rwczf8XC/KqnB+ffpcsGnxRaEGB3xZqpmzH6xfMzKGKCVpULpxpgBfKK1RUthZB4MtlfN5f5TNKX/7p5P/d97Y1Lb9N9ELD7rQQz29p8edcGdn; 25:27rKkwTr8eS9JvJ3HT205VSqH9yHzmzReFsmYzhPlx50GWjhIU4IHsmzsDuGgz6jJp6s/eZoLvC5YZ4pxTIogMZVVYuzEiVmd/VaOVH6FoSoL2Ovmzd68IbIxCB6DZFIqR8ryXUk6nRzIv1EXDDu4v7XOad9HhM/xjbrwgz3CUbVfEy9Hv9+QrF9i26oXx6znQMjW4cai8tUkVs938VGbQpOJfXuPVGsBJsP7d3yH/XClxFTSUcHEeTIdT8R4pzVIwydbwwuNnOtsSnP0s+ZqKRZFsrTPE4Ts2gu71znTTgMEsg9XvTd/YINSG2uBXYow0sgUu61Hc5HnYL2mRwzKw==; 31:Ilk9vcqskprpb9sZlW/yofQMdw5f8xmDdasp/Er8W2/s4m0rSvt+7SvZelk9PAddVv5M9ctqfSWXnVzfQji7+Y/l8MQsAyNtpTC4piHaXymCGzLvi/WTeG3gL3vqNAf2hIjl8TPCTzO0EaSkwI5DPotZ9m2od2TEjh7XmrG+Q/XR2kkhvaS7rgsXeapkzIsRfKRYMzNODbmlVhI/Rpcy4ZR6H81XNJuyxs1ZJD9ohik= X-MS-TrafficTypeDiagnostic: AM4PR01MB1825: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(28532068793085)(158342451672863)(278428928389397)(120809045254105)(192374486261705)(213716511872227)(21532816269658)(123452027830198)(17755550239193)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(10201501046)(6041310)(20161123564045)(20161123558120)(20161123562045)(2016111802025)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:AM4PR01MB1825; BCL:0; PCL:0; RULEID:; SRVR:AM4PR01MB1825; X-Microsoft-Exchange-Diagnostics: 1; AM4PR01MB1825; 4:0EPWhw8Lv85yxi5HVcqSS6leV5mq3SsLSxDJw64ZSaKWIjM12k1kBw6Nxz4n3VjqWAPMbc4JQGubQfO/cvQzMDv5ZDR2dED/gt4jQQZJokVRDiyZ1TlbtlPMvxnAqHoJanu2tz7u2jeKT7/3NkmFC8VFjWqlN+TvVom1twDRmhGbbyKyFfKBXGZxshW7/sVsRIq/3G12KvG73N/H0tY1h/5SlQhfVFGS+5bZImiZMKv3IYIhXoohCTWXXfGNhF0rW0xcSu5cW/tgf9fU3brub8ZaYbKECIzv1gpqxexTaoWIBAwcjNw4IWVB5ZydWvmjHVSJEdvW17agxF0dq9nQayd8xjzy9z9kR6g6y7rPJjflPk/xfKHEVroOevtVUIcdVg3+uatl1wrk+oaA/dksNcFIba+2q/8ed6XicQqhOnUOL81Z2aVsuI/a5NIn5Xhcg5BUGZQUjvDvssJZ8mSH9SFgQK7DwNTWPIs7YfHLKcJwYfN6+ilKsrKlhA4PlVirFuvFxpltUAHDXeCbF1bCRezf9Gw2eDyWc6KIG6AqSUPTUvXdFmeBxIPEkGibalrOVQM4do25yuSEUKz0KciVRiwsGEAKXa4XL56H7HaGGgpjX2Kpqb89C+QV3eWYiMJd X-Forefront-PRVS: 06339BAE63 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39830400003)(346002)(366004)(39380400002)(376002)(396003)(38534002)(189003)(199004)(13464003)(377424004)(7826002)(61296003)(61793004)(44736005)(316002)(71636004)(110136005)(478600001)(53936002)(93886005)(561944003)(16586007)(66066001)(81156014)(6666003)(81166006)(2906002)(25786009)(96836002)(5660300001)(105586002)(84116003)(50226002)(7736002)(8936002)(8676002)(39060400002)(18717965001)(33964004)(53546011)(33896004)(84326002)(76176011)(59450400001)(52116002)(36756003)(186003)(3846002)(11346002)(6116002)(966005)(6496006)(97736004)(386003)(476003)(26005)(16526019)(486006)(106356001)(956004)(102836004)(16200700003)(68736007)(446003)(53946003)(236005)(54896002)(1420700001)(14726001)(6306002)(6486002)(9686003)(790700001)(606006)(21314002)(2101003)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR01MB1825; H:Kallei7; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: ingate.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjAxTUIxODI1OzIzOi9zamJWSjdUeW9DVDg5MjJ0UjdXNFI0TTg4?= =?utf-8?B?TTAzUjM5NXFwVTJZY3NNYmNKa0lpUzJsVW0zNGxpangxV2d0UXN5eUh0MTlO?= =?utf-8?B?cjdyQ1VXcGlaQTE4czNIVE9ZSURMNlNqcUZMd1MxNzdCd3luWkozK2hDOCty?= =?utf-8?B?WUg3Qy9tSnlyejE4RTFpTGJCREw2RGpReTBDUlROVFY3cGVuMEgxTFhCTEVr?= =?utf-8?B?bFRPbGphWVphZDBaRjA3U2s4N1oxOHU3K0pFTkJESzAzK1NBaEloYk5PeHRw?= =?utf-8?B?SjRhWi9sRlBhenBsa3FFY2g5RkFkK0Q0MkV6bmNIV2lBMjNQZWo3TC9za1JB?= =?utf-8?B?TlV4anZEb2plVVJvUXJFMXlIZkhJdFo2K0RkT1FjeVN3dDV4TFMxaDBIQ1NX?= =?utf-8?B?elJVNHFlTnd0NEhCVG5JcHF2dGNOeit6eUlwRjFaNHo5ak9tRWUzcC9oY0Vr?= =?utf-8?B?bURlVFdGR2xYWFVmOWpZMU1KdHZtVWVjcVhxQ1lwbEZwak5RSGphVWthc25m?= =?utf-8?B?TEZLS2Z5dDcvTUZ3U1hHOC95UXNPM294OFc4bDZ5MmV3NXl2aWw1NjlsRnYw?= =?utf-8?B?a0JwS0NCRXdUclJkRTlwcm5xci8zcGhUdjB3elhiSm10V01CYmlqd2drMndN?= =?utf-8?B?YkZCMGdqaVA4anhUNnB1NTdWcHp1THJWeGVFOVByWDZFa3dCK1JMT2RTbE1o?= =?utf-8?B?YTRYNFBHOXRSOU9sb1ZaZXVpdzFSaVpRRkhxMGdpTE9rSUFocHhjUUd2T3Nl?= =?utf-8?B?UXZ6UFJsUFYweUVzeFE2R1VOWi9RQkJoa244L3dRSGhPVWc1VVFXNmkyV3BB?= =?utf-8?B?WHZqOVBubnBCSkZHc3B3VlAzbjQ3cEd6S294bWpwSW1ack1XYVJqODJhekFR?= =?utf-8?B?WFZwS2kwUWJxYmtxSW95OHhnajBvZnBOVk1OQ0ZVZ0x1SENRajNZZVJ6bWcv?= =?utf-8?B?SHg3VFl3c00weXhZMzNaT1BKWGZNRDlXalAyY0QzVXBPaGMyclZhR0xvdlpu?= =?utf-8?B?bVhXbXZUN3ArY0J3cktJaTc1WVBKSWpBT0FqcXZGY3JpQ0FPTmZVTG16bHlu?= =?utf-8?B?TDFITFk5bUx0MDFwTnNaL1Qra3d2VjlleFlwZDlsVFFodnR0Z2EyN2dmMzk2?= =?utf-8?B?bGJDeXZab29VSHdJeGpONS9LZzRObC9xQTVwMVRDU2dzQkE1SS9XY0FCaWhu?= =?utf-8?B?dTNkOWNMNStDSU5MMWpwOVQ0RTIrYXVqdDg3QnA1UnYvYTFLNGxEbkZsTmRi?= =?utf-8?B?cHpvK2QwUHR6RmhNK0srSGk3KzIwM3RHVWQ0ZFphaFpSZkF5ZUp6RExIRFJU?= =?utf-8?B?SXp3dS91SXQrYUhHSTVmTm5uRHdiZ2h0ckg0YXF6SUNSbXhYZFAwRzdRQjhM?= =?utf-8?B?VkREY1REU3kyVDVkWnFpVExrQU5LY3ZRTFd3cTZDaWJsZm13OUdQSDBzUTV5?= =?utf-8?B?UU1aQzY0cHJ1TGFaRXhOZXkxMUNTRHlhVmY5ZUNXSElaNS9Zbk05cFEramdE?= =?utf-8?B?UmEyOFY2cDZXK3JNdnpvMUg3b0dhcVJORDMxMUZiWmU1bGRYZVlNV00vN1NE?= =?utf-8?B?bTAyUXh6KytUU0s0WWpJNzZHdFpIVk5vMzljbENYcnhUVFRUazF3VXJ0aFlK?= =?utf-8?B?VEU1Y0lZaHhpNEM1VGExWlpqbDYwZjlQOVAwSHFDa2xlU1QxN3R5M09IczRn?= =?utf-8?B?eUpydU9FTy9mL01zMk5nWkEvdkhLVERDSHdXRWJVZVhBVFJkVHgyS2VBU1ox?= =?utf-8?B?OHZiMDNMWTV0amU3Z0d2eGp2TmRMMnNkVktaZkxEY2ZnWWdXZmZySUl5ZGJq?= =?utf-8?B?VkRBeFVRVU5TbHBRa0phZlVFQ01SVFY4RTFKY05ValhQRUxQTS9OUUhyZ05H?= =?utf-8?B?ZFo2K3I2SkQvczhFdXJ6cHlSVWpPNEw1aUY1Y2NPT2MyK2pweG5PTDZLcUY5?= =?utf-8?B?YzJQRHZ0blZHZWtxbVQ2ZWhXWnJjZVplaHltTjlwSjdYVGFQaDdyeStrQzJL?= =?utf-8?B?L3ZXVU4xbkcza3p5c0NLVEV3ZUxPL3U1MHc2N2NFZEpPOGR5NHFJRTFqWjNJ?= =?utf-8?B?REd3YlZXamszdkxGRXlKMndCQVNsRkwwT3I3N1VHa0I3Mm5ObzJjMk9YQzRu?= =?utf-8?B?KzBINHpsemlQNGFpbHFpVVAranBmcnh0OGpKYjRVVVJyaFlObTEvYjM0OFk0?= =?utf-8?B?eFhQS3RUeHBVc2Rob2dVWWQ5aHJPYTQ3d0xBTlYyZm44SFl2TWQrdzNreFh0?= =?utf-8?B?TkVEY0VnSmN3ekxkeHc3cjQ4b1NVTVRmTWxTK3FEUTlrVDhFcVFQWFdCWW13?= =?utf-8?Q?zD5Kmdyad8XGKUAO46uMuyqdaOjmLT3L+uh9n?= X-Microsoft-Antispam-Message-Info: MqjgFMUFsNxVLV4kDkGQ0+uGy99AL1j6rmyJ5Mv49a+SfI8kcOrBYbTC7FW+JebtZ12Iy4Mx9Vc3roZUxfDFwnaiTtC6rFt2vpB6R+HGtyXSWWOUBTRPS5yjwvpQjIoWlFSWJk4Yurcm6M+fOEJxWDo8M5A3ONcbngfTIoeLTZnLyBhRVReJ1aplxboWEjck X-Microsoft-Exchange-Diagnostics: 1; AM4PR01MB1825; 6:hdEuNRZdIx4tjjm6EEuz5r7U62jwNABjX8E8se87jdAnlGn2EbNdZoxrSH8TVEaVNsy34PK0FBHTYpVj67kT/KY5aIFlMK9/TFp3zlGDe+gNLEb3BZ1rb5fVMis1Bq8Ybq/MdcDB5Y7juJO/9Cw8q3v3KPuSMroJk0Hek5Iy6DzrbXkO2aX3cbMcP4W4DxavaMKciiJSjhrZ9ydbyXKMPJ9/rDEa2IXjKQ/pzHp/PxVaRf0k24vtyoYVdBbxO3lvsmVUcGQ6v6lSc3J7jz18SCdbhQwQsKDI8mf808pOP9NsjZXo7Wqg2IixSYahxqzwvzgLRns+6BUVfGmheyjU3xSiMLQq0/LBCMsHQ1nH+j2YDEqKJn4Nr8KJiBjgYrs8CJzFH25Wy/cKMNvQKxwc8iwzpuGeamRahoiqCNUaOsRitId9mSHgywnUMbeiuzD20Vw0Uxs27szHUBueD0zd4Q==; 5:74+xZhhqxx1PQVJE0mqRE/dTxqkQaQMSVOPenobLdrrcULsm5zW2B6oOsz4abuJFYNhmNrY87uexGIy3fYWpPFduYZNJBYpniNmyAlpdWD8a8cJTQrzQcDBRvmsYvZMsQJAp0Z2+PUkAkRA7EI4IMzXj2MEPa+do1aNBp8diyRo=; 24:Rr/8Z+c2to8vGJYTk16IkkuEDy13c3s2fzWRq3ikUJ5iBhWAEtsUvJ1IKh949QYNFNIxCFlLiyao1P1HNWdhm1dfgtcoH7cLYy0WIfKI0Lg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM4PR01MB1825; 7:bmv9Bzf2TkajcsIPxnTxCCivuAdwUFf/D41iC0T4UVBcec2Pxv8YsGO84f/QSwTrdUYdgLKLO9kKhNdaRppWud92jXPOz2WC8COcsgWXBSFfO+MCpm3LNiTqT/tHGcgkcgamcNOy22zH0X+663DBac3eq1nvAp22xScTCx6GF/cJMyqLn80NAbGJBZStN8Xc3Jr23D2O6hfKFXQ1M1So4aovTUNCtvlV4XK2c71t7pEfO6OFCp+mO2ietIyHy3Lm X-OriginatorOrg: ingate.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2018 15:52:37.1546 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fe942a94-4aa5-4d14-1986-08d59b0d4155 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c3eda49a-3ed0-46c6-8a9e-d0d8ce3d2fae X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR01MB1825 Archived-At: Subject: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.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, 05 Apr 2018 15:52:47 -0000 ------=_NextPart_000_01B2_01D3CD06.E6A72D50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Noriyoki, Answering in-line below with cuts from drafts/RFCs how the = network provided turn server came to be (which is why we need the = generalization to multiple allocation) and jumping back on the other = thread to explain the application (that real-time media is not only over = public Internet =E2=80=93 actually, current VoIP is typically on = separate (quality) networks) =20 And Olle, last below (what came first) =E2=80=9CNetwork-provided servers = was added to the security section of RFC 8155=E2=80=A6=E2=80=9D=E2=80=93 = It was the other way around! What became RFC 8155 was intended to be = TURN server discovery mechanism for enterprises and ISPs. That is = Network Provided TURN servers in the local or access network =E2=80=93 = Not Brandon=E2=80=99s TURN servers that are elsewhere (but discovered). =20 /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Noriyuki Torii Skickat: den 5 april 2018 05:29 Till: tram@ietf.org =C3=84mne: Re: [tram] Multiple allocations SV: I-D Action: = draft-ietf-tram-turnbis-15.txt =20 Hi, =20 >From my understandings, current TURNbis specification is intended, as = its scope of, just a single IP addressed server nevertheless its IPv4/v6 co-allocation capability. Such a capablity is introduced for v4 <-> v6 communication, and not as a generalization for a multiple IP addressed server. =20 [KS] --- That is the way it has happened (in contrast to = intended/understood considering why TRAM was formed, charter = https://datatracker.ietf.org/wg/tram/about and the overall need for a = TURNbis) =20 =20 IMHO, if a server with multiple IP addresses of the same family will be deployed into service, idential form of allocation request currently defined also should be sent to such a server. And the server must = process the request appropriately according to its network configuration. =20 In general, clients don't know, and shouldn't need to know, how many IP addresses are given to the server communicating with, or how is the topology of the network into where the server is deployed, etc. So the client side request form selection is not usually possible. =20 [KS] --- That is totally changed with the network provided TURN server=20 =20 In ICE style, to get all candidates: * With application provided TURN servers, the Client is given all TURN = servers (into different networks) to Allocate multiple times. * With network provided TURN servers, the Client needs to get all = candidates in one go (One Allocation to that single network provided = TURN server, that it has found somehow). =20 =20 THE NETWORK PROVIDED TURNSERVER COMES FROM: RFC7478 https://tools.ietf.org/html/rfc7478=20 Web Real-Time Communication Use Cases and Requirements =20 2.3.2. Simple Video Communication Service: NAT/Firewall That Blocks UDP =20 2.3.2.1. Description =20 This use case is almost identical to the Simple Video Communication Service use case (Section 2.3.1). The difference is that one of the users is behind a NAT/firewall that blocks UDP traffic. =20 2.3.2.2. Additional Requirements =20 ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F18 The browser must be able to send streams and data to a peer in the presence of NATs and firewalls that block UDP traffic. ---------------------------------------------------------------- =20 2.3.3. Simple Video Communication Service: Firewall That Only Allows =20 Traffic via an HTTP Proxy =20 2.3.3.1. Description =20 This use case is almost identical to the Simple Video Communication Service use case (Section 2.3.1). The difference is that one of the users is behind a firewall that only allows traffic via an HTTP Proxy. =20 2.3.3.2. Additional Requirements =20 ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F21 The browser must be able to send streams and data to a peer in the presence of firewalls that only allow traffic via an HTTP Proxy, when firewall policy allows WebRTC traffic. ---------------------------------------------------------------- =20 2.3.4. Simple Video Communication Service: Global Service Provider =20 2.3.4.1. Description =20 This use case is almost identical to the Simple Video Communication Service use case (Section 2.3.1). What is added is that the service provider is operating over large geographical areas (or even globally). =20 Assuming that the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] will be used, this means that the service provider would like to be able to provide several Session Traversal Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) servers (via the app) to the browser; selection of which one(s) to use is part of the ICE processing. Other reasons for wanting to provide several STUN and TURN servers include support for IPv4 and IPv6, load balancing, and redundancy. =20 Note that ICE support being mandatory does not preclude a WebRTC endpoint from supporting more traversal mechanisms than ICE using STUN and TURN. =20 2.3.4.2. Additional Requirements =20 ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F19 The browser must be able to use several STUN and TURN servers. ---------------------------------------------------------------- =20 A22 =20 2.3.5. Simple Video Communication Service: Enterprise Aspects =20 2.3.5.1. Description =20 This use case is similar to the Simple Video Communication Service use case (Section 2.3.1). =20 What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use case. =20 An enterprise that uses a WebRTC-based web application for communication desires to audit all WebRTC-based application sessions used from inside the company towards any external peer. To be able to do this, they deploy a TURN server that straddles the boundary between the internal and the external network. =20 The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using WebRTC applications provided by an external service provider, they still want the traffic to stay inside their internal network and in addition not load the straddling TURN server; thus, they deploy a STUN server allowing the WebRTC client to determine its server reflexive address on the internal side. Thus, enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by autoconfiguration methods. The WebRTC functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. =20 [KS continuing] That TURN server that straddles the boundary between the internal and the external network + is the network provided TURN server in the local or access network = [terminology used in = https://www.rfc-editor.org/rfc/pdfrfc/rfc8155.txt.pdf]=20 + and in the TRAM CHARTER is the (among milestones:) Nov 2015 Send new TURN server discovery mechanism for enterprises and = ISPs to IESG for publication as Proposed Standard = draft-ietf-tram-turn-server-discovery =20 + and in https://www.ietf.org/archive/id/draft-ietf-rtcweb-return-02.txt = TURN Proxy or Border TURN server =20 Brandon=E2=80=99s Network Provided TURN servers are OUTSIDE the local or = access network and it is very unfortunate that = https://www.rfc-editor.org/rfc/rfc8155.txt took that as the main = approach =E2=80=9CThis document describes three discovery mechanisms, so = as to maximize the opportunity for discovery, based on the network in = which the TURN client finds itself.=E2=80=9D (We definitely = don=E2=80=99t want to find Brandon=E2=80=99s turn servers when trying to = discover the very private TURN server on the LAN =E2=80=93 unfortunately = making RFC 8155 more or less useless for its intended purpose: = Autodiscovery of the network provided TURN server in the local and = access network.) =20 =20 (And Olle: Your statement in other email =E2=80=9CWell, since = Network-provided servers was added to the security ection of RFC 8155, I = kind of think it=E2=80=99s now in scope for everything TURN and from = that standpoint I do understand Karl=E2=80=99s objections.=E2=80=9D = =E2=80=93 It was the other way around! What became RFC 8155 was intended = to be TURN server discovery mechanism for enterprises and ISPs.) =20 Enough of history now. And back to the other thread and the need for = having real-time media on multiple WAN networks (heavily used for VoiP = for over 10 years). =20 The Network Provided TURN Server in the local or access network, is = really about finally resolving the NAT/Firewall traversal problem of = real-time communication. After all these (15?) years, we cannot have a = TURNbis RFC that in itself hinders its usage (only to use with real-time = media on the public Internet =E2=80=93 which rarely is the case). =20 =20 [Noriyuki=E2=80=99s text again] =20 Because of above, I'm afraid to say but I couldn't agree with the Karl's proposal of the modification of request form with additional attributes, although I can understand there exists the demand of specification for multiple IP addressed server. =20 I think the generalization of TURN for multiple IP addressed server is something need more discussion and separate publication. =20 Regards, Noriyuki Torii =20 2018-03-21 4:55 GMT+09:00 Karl Stahl < = karl.stahl@ingate.com>: >> This revision addresses comments from Mark, Karl and Noriyuki Torii. > My comment about need for multiple allocations is NOT addressed. >=20 > Let me explain more clearly why multiple allocations is needed: >=20 > ICE is about finding all/many paths for the media, e.g. with the help = of > TURN servers. > Those paths are not over ONE IPv4 network, over ONE IPv6 network or = EXACTLY > ONE OF EACH. > If fact, it is more common that you have several IPv4 networks paths. >=20 > Now that we have network provided TURN servers, you only ask for = Allocation > once (contrary to application provided TURN servers, where you can be > directed to Allocate several times.) and thus we need all relay = addresses in > one allocation request. >=20 > Wasn't that the reason dual allocation was requested? The need for = multiple > allocation is stronger! >=20 > Please address this, e.g. like below (seems you are almost there). >=20 > /Karl >=20 >=20 > ******************* Previous ******************* >=20 > Allowing a turn allocation to return multiple relayed transport = addresses, > beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on = different > interfaces/network segments), seems like very small step now when the = dual > allocation was put in place in this draft. We certainly need it (some > reasons below) if TURN is going to be used where needed and we cannot = wait > for any additional draft. >=20 > Seems like it is sufficient to extent this table (found in draft 14) = with 3 > new values (as shown): >=20 > 16. STUN Attributes >=20 > This STUN extension defines the following attributes: >=20 > 0x000C: CHANNEL-NUMBER > 0x000D: LIFETIME > 0x0010: Reserved (was BANDWIDTH) > 0x0012: XOR-PEER-ADDRESS > 0x0013: DATA > 0x0016: XOR-RELAYED-ADDRESS > 0x0017: REQUESTED-ADDRESS-FAMILY > 0x0018: EVEN-PORT > 0x0019: REQUESTED-TRANSPORT > 0x001A: DONT-FRAGMENT > 0x0021: Reserved (was TIMER-VAL) > 0x0022: RESERVATION-TOKEN > TBD-CA: ADDITIONAL-ADDRESS-FAMILY > ADDITIONAL-ADDRESS-ALL > ADDITIONAL-ADDRESS-ALLV4 > ADDITIONAL-ADDRESS-ALLV6 > TBD-CA: ADDRESS-ERROR-CODE > TBD-CA: ICMP >=20 > Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, = very > little text seems to be added for generalization to = ADDITIONAL-ADDRESS-xxx. > Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be reused. >=20 > ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN = client. >=20 > Check! - We need this now. >=20 > Thanks, > Karl >=20 >> -----Original Message----- >> From: Karl Stahl [ = mailto:karl.stahl@ingate.com] >> Sent: Sunday, March 4, 2018 10:36 PM >> To: 'Marc Petit-Huguenin' < = petithug@acm.org>; Konda, Tirumaleswar Reddy >> < = TirumaleswarReddy_Konda@McAfee.com>; = tram@ietf.org >> Subject: SV: [tram] Review of dual allocation in TURNbis-11 >>=20 >> Hi, >>=20 >> When we now have "dual allocation" into this draft (I see on page 26: = "If > the >> client wishes to obtain one IPv6 and one IPv4 relayed transport = address > then >> it includes an ADDITIONAL-ADDRESS-FAMILY transport address then it") = can >> we not generalize that further and allow MORE THAN ONE relayed = transport >> address (of any family) in response to an allocation? >>=20 >> I mean that a TURN server could have several relay interfaces at = different > IP- >> addresses into different networks - not just the Internet, but also a = VoIP >> (higher quality) network e.g. by some triple play service provider, = an IMS >> network or some branch office network. >>=20 >> I think this is specifically important for network provided/auto > discovered >> turn servers (application provided turn servers could instead just = list > several >> turn servers). >>=20 >> I saw someone snipped this about "SINGLE relayed transport address = per >> allocation request" >> > > = https://tools.ietf.org/html/rfc6156#section-3 >> > > >> > > >> > > TURN servers allocate a single relayed transport address per >> > > allocation request. Therefore, Allocate requests cannot carry = more >> > > than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a >> client >> > > that wishes to allocate more than one relayed transport = address at > a >> > > TURN server (e.g., an IPv4 and an IPv6 address) needs to = perform >> > > several allocation requests (one allocation request per = relayed >> > > transport address). >> > > >>=20 >> but if that is remedied now, it seems like a small step to generalize = so > we can >> get multiple relayed transport addresses from one allocate request? >>=20 >> /Karl >=20 >=20 > -----Ursprungligt meddelande----- > Fr=C3=A5n: tram [ = mailto:tram-bounces@ietf.org] F=C3=B6r Konda, Tirumaleswar Reddy > Skickat: den 18 mars 2018 09:51 > Till: tram@ietf.org > =C3=84mne: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt >=20 > This revision addresses comments from Mark, Karl and Noriyuki Torii. >=20 > -Tiru >=20 >> -----Original Message----- >> From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Sunday, March 18, 2018 8:43 AM >> To: i-d-announce@ietf.org >> Cc: tram@ietf.org >> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt >>=20 >>=20 >> 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. >>=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-15.txt >> Pages : 84 >> Date : 2018-03-18 >>=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-15 >> = https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-15 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-15 >>=20 >>=20 >> 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. >>=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 >=20 > _______________________________________________ > 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 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram ------=_NextPart_000_01B2_01D3CD06.E6A72D50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Noriyoki, Answering in-line below with cuts from = drafts/RFCs how the network provided turn server came to be = (which is why we need the generalization to multiple allocation) and = jumping back on the other thread to explain the application (that = real-time media is not only over public Internet =E2=80=93 actually, = current VoIP is typically on separate (quality) = networks)

 

And Olle, last below (what came first) = =E2=80=9CNetwork-provided servers was added to the security section of = RFC 8155=E2=80=A6=E2=80=9D=E2=80=93 It was the other way around! What = became RFC 8155 was intended to be TURN server = discovery mechanism for enterprises and ISPs. That is Network Provided TURN servers = in the local or access network =E2=80=93 Not Brandon=E2=80=99s TURN = servers that are elsewhere (but discovered).

 

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] = F=C3=B6r Noriyuki Torii
Skickat: den 5 april 2018 = 05:29
Till: tram@ietf.org
=C3=84mne: Re: [tram] Multiple = allocations SV: I-D Action: = draft-ietf-tram-turnbis-15.txt

 

Hi,

 

>From my understandings, current TURNbis = specification is intended, as its

scope of, just a single IP addressed server = nevertheless its IPv4/v6

co-allocation capability. Such a capablity is = introduced for v4 <-> v6

communication, and not as a generalization for a = multiple IP addressed

server.

 

[KS] --- That is the way it has = happened (in contrast to intended/understood considering why TRAM was = formed, charter https://datatracker.i= etf.org/wg/tram/about and the overall need for a = TURNbis)

 

 

IMHO, if a server with multiple = IP addresses of the same family will be

deployed into service, idential form of allocation = request currently

defined also = should be sent to such a server. And the server must = process

the request appropriately = according to its network configuration.

 

In = general, clients don't know, and shouldn't need to know, how many = IP

addresses are given to the = server communicating with, or how is the

topology of the network into where the server is = deployed, etc.

So the client side = request form selection is not usually possible.

 

[KS] --- That is totally changed with = the network provided TURN server

 

In ICE = style, to get all candidates:

* With = application provided TURN servers, the Client is given all TURN servers = (into different networks) to Allocate multiple = times.

* With network provided TURN servers, the Client = needs to get all candidates in one go (One Allocation to that single = network provided TURN server, that it has found = somehow).

 

 

THE = NETWORK PROVIDED TURNSERVER COMES FROM: = RFC7478

https://tools.ietf.org/html/= rfc7478

Web Real-Time Communication Use Cases = and Requirements

 

2.3.2.=C2=A0 Simple Video Communication Service: = NAT/Firewall That Blocks UDP

 

2.3.2.1.=C2=A0 Description

 

=C2=A0=C2=A0 This use case is almost identical to = the

=C2=A0=C2=A0 Simple Video Communication Service = use case (Section 2.3.1).=C2=A0 The

=C2=A0=C2=A0 difference is that one of the users = is behind a NAT/firewall that

=C2=A0=C2=A0 blocks UDP = traffic.

 

2.3.2.2.=C2=A0 Additional = Requirements

 

=C2=A0=C2=A0 = ----------------------------------------------------------------

=C2=A0=C2=A0 = REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = DESCRIPTION

=C2=A0=C2=A0 = ----------------------------------------------------------------

=C2=A0=C2=A0 = F18=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= The browser must be able to send streams and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data to a peer = in the presence of NATs and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 firewalls that = block UDP traffic.

=C2=A0=C2=A0 = ----------------------------------------------------------------

 

2.3.3.=C2=A0 Simple Video Communication Service: = Firewall That Only Allows

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Traffic = via an HTTP Proxy

 

2.3.3.1.=C2=A0 Description

 

=C2=A0=C2=A0 This use case is almost identical to = the

=C2=A0=C2=A0 Simple Video Communication Service = use case (Section 2.3.1).=C2=A0 The

=C2=A0=C2=A0 difference is that one of the users = is behind a firewall that only

=C2=A0=C2=A0 allows traffic via an HTTP = Proxy.

 

2.3.3.2.=C2=A0 Additional = Requirements

 

=C2=A0=C2=A0 = ----------------------------------------------------------------

=C2=A0=C2=A0 = REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = DESCRIPTION

=C2=A0=C2=A0 = ----------------------------------------------------------------

=C2=A0=C2=A0 = F21=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= The browser must be able to send streams and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data to a peer = in the presence of firewalls that only

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 allow traffic = via an HTTP Proxy, when firewall policy

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 allows WebRTC = traffic.

=C2=A0=C2=A0 = ----------------------------------------------------------------

 

2.3.4.=C2=A0 Simple Video Communication Service: = Global Service Provider

 

2.3.4.1.=C2=A0 Description

 

=C2=A0=C2=A0 This use case is almost identical to = the

=C2=A0=C2=A0 Simple Video Communication Service = use case (Section 2.3.1).=C2=A0 What is

=C2=A0=C2=A0 added is that the service provider is = operating over large

=C2=A0=C2=A0 geographical areas (or = even globally).

 

=C2=A0=C2=A0 Assuming that the Interactive = Connectivity Establishment (ICE)

=C2=A0=C2=A0 mechanism [RFC5245] will be used, = this means that the service

=C2=A0=C2=A0 provider would like to be able to = provide several Session Traversal

=C2=A0=C2=A0 Utilities for NAT (STUN) and = Traversal Using Relay NAT (TURN) servers

=C2=A0=C2=A0 (via the app) to the browser; = selection of which one(s) to use is

=C2=A0=C2=A0 part of the ICE processing.=C2=A0 = Other reasons for = wanting to provide

=C2=A0=C2=A0= several STUN and TURN servers include support for IPv4 and = IPv6, = load

=C2=A0=C2=A0 balancing, and = redundancy.

 

=C2=A0=C2=A0 Note that ICE support being mandatory = does not preclude a WebRTC

=C2=A0=C2=A0 endpoint from supporting more = traversal mechanisms than ICE using

=C2=A0=C2=A0 STUN and = TURN.

 

2.3.4.2.=C2=A0 Additional = Requirements

 

=C2=A0=C2=A0 = ----------------------------------------------------------------

=C2=A0=C2=A0 = REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = DESCRIPTION

=C2=A0=C2=A0 = ----------------------------------------------------------------

=C2=A0=C2=A0 = F19=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= The browser must be able to use several STUN

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and TURN = servers.

=C2=A0=C2=A0 = ----------------------------------------------------------------

 

=C2=A0=C2=A0 A22

 

2.3.5.=C2=A0 Simple Video Communication Service: = Enterprise = Aspects

 

2.3.5.1.=C2=A0 Description

 

=C2=A0=C2=A0 This use case is similar to the = Simple Video Communication Service

=C2=A0=C2=A0 use case (Section = 2.3.1).

 

=C2=A0=C2=A0 What is added is aspects when using = the service in enterprises.=C2=A0 ICE

=C2=A0=C2=A0 is assumed in the further description = of this use case.

 

=C2=A0=C2=A0 An enterprise that uses a = WebRTC-based web application for

=C2=A0=C2=A0 communication desires to audit all = WebRTC-based application sessions

=C2=A0=C2=A0 used from inside the company towards = any external peer.=C2=A0 To be able

=C2=A0=C2=A0 to do this, they deploy a TURN server that = straddles the boundary

=C2=A0=C2=A0= between the internal and the external network.

 

=C2=A0=C2=A0 The firewall will block all attempts = to use STUN with an external

=C2=A0=C2=A0 destination unless they go to the = enterprise auditing TURN server.

=C2=A0=C2=A0 In cases where employees are using = WebRTC applications provided by an

=C2=A0=C2=A0 external service provider, they still = want the traffic to stay inside

=C2=A0=C2=A0 their internal network and in = addition not load the straddling TURN

=C2=A0=C2=A0 server; thus, they deploy a STUN = server allowing the WebRTC client to

=C2=A0=C2=A0 determine its server reflexive = address on the internal side.=C2=A0 Thus,

=C2=A0=C2=A0 enabling cases where peers are both = on the internal side to connect

=C2=A0=C2=A0 without the traffic leaving the = internal network.=C2=A0 It must be

=C2=A0=C2=A0 possible to configure the browsers = used in the enterprise with

=C2=A0=C2=A0 network specific STUN and TURN = servers.=C2=A0 This should be possible to

=C2=A0=C2=A0 achieve by autoconfiguration = methods.=C2=A0 The WebRTC functionality = will

=C2=A0=C2=A0 need to utilize both network specific = STUN and TURN resources and

=C2=A0=C2=A0 STUN and TURN servers provisioned by = the web application.

<end cut from RFC = 7478>

 

[KS = continuing] That TURN server that = straddles the boundary

=C2=A0=C2=A0= between the internal and the external network

+ is the = network provided = TURN server in the local or access network [terminology = used in https://ww= w.rfc-editor.org/rfc/pdfrfc/rfc8155.txt.pdf] =

+ and in the TRAM CHARTER is the (among = milestones:)

Nov 2015=C2=A0 Send new TURN server discovery = mechanism for enterprises and ISPs to IESG for publication = as Proposed Standard draft-ietf-tram-turn-server-discovery=C2=A0 =

+ and in = https://www.ietf.org/archive/id/draft-ietf-rtcweb-return-02.txt =

TURN Proxy = or Border TURN server

 

Brandon=E2=80=99s Network Provided TURN servers = are OUTSIDE the local or access network and it is very unfortunate that = https://www.rfc-edito= r.org/rfc/rfc8155.txt took that as the main approach = =E2=80=9CThis document describes three = discovery mechanisms, so as to maximize the opportunity for discovery, = based on the network in which the TURN =C2=A0=C2=A0=C2=A0client finds = itself.=E2=80=9D (We definitely don=E2=80=99t want to find = Brandon=E2=80=99s turn servers when trying to discover the very private = TURN server on the LAN =E2=80=93 unfortunately making RFC 8155 more or = less useless for its intended purpose: Autodiscovery of the network = provided TURN server in the local and access network.) = =C2=A0

 

(And Olle: Your statement in other email =E2=80=9CWell, = since Network-provided servers was added to the security ection of RFC = 8155, I kind of think it=E2=80=99s now in scope for everything TURN and = from that standpoint I do understand Karl=E2=80=99s objections.=E2=80=9D = =E2=80=93 It was the other way around! What became RFC 8155 was intended = to be TURN server = discovery mechanism for enterprises and ISPs.)

 

Enough of = history now. And back to the other thread and the need for having = real-time media on multiple WAN networks (heavily used for VoiP for over = 10 years).

 

The = Network Provided TURN Server in the local or access network, is really = about finally resolving the NAT/Firewall traversal problem of real-time = communication. After all these (15?) years, we cannot have a TURNbis RFC = that in itself hinders its usage (only to use with real-time media on = the public Internet =E2=80=93 which rarely is the = case).

 

 

[Noriyuki=E2=80=99s text = again]

 

Because of above, I'm afraid to = say but I couldn't agree with the Karl's

proposal of the modification of request form with = additional attributes,

although I = can understand there exists the demand of specification = for

multiple IP addressed = server.

 

I think the generalization of TURN for multiple IP = addressed server is

something need = more discussion and separate publication.

 

Regards,

Noriyuki Torii

 

2018-03-21 4:55 GMT+09:00 Karl Stahl <karl.stahl@ingate.com>:

>> This = revision addresses comments from Mark, Karl and Noriyuki = Torii.

> My comment about need = for multiple allocations is NOT addressed.

> 

> Let me explain more clearly why multiple = allocations is needed:

> 

> ICE is about finding all/many paths for the = media, e.g. with the help of

> = TURN servers.

> Those paths are = not over ONE IPv4 network, over ONE IPv6 network or = EXACTLY

> ONE OF = EACH.

> If fact, it is more = common that you have several IPv4 networks paths.

> 

> Now that we have network provided TURN = servers, you only ask for Allocation

> once (contrary to application provided TURN = servers, where you can be

> = directed to Allocate several times.) and thus we need all relay = addresses in

> one allocation = request.

> 

> Wasn't that the reason dual allocation was = requested? The need for multiple

> allocation is stronger!

> 

> Please address this, e.g. like below (seems = you are almost there).

> 

> /Karl

> 

> 

> ******************* Previous = *******************

> 

> Allowing a turn allocation to return multiple = relayed transport addresses,

> = beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on = different

> interfaces/network = segments), seems like very small step now when the dual

> allocation was put in place in this draft. We = certainly need it (some

> = reasons below) if TURN is going to be used where needed and we cannot = wait

> for any additional = draft.

> 

> Seems like it is sufficient to extent this = table (found in draft 14) with 3

> new values (as shown):

> 

> 16.=C2=A0 STUN Attributes

> 

>=C2=A0=C2=A0=C2=A0 This STUN extension defines = the following attributes:

> 

>=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A00x000C: = CHANNEL-NUMBER

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x000D: = LIFETIME

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x0010: Reserved = (was BANDWIDTH)

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x0012: = XOR-PEER-ADDRESS

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x0013: = DATA

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x0016: = XOR-RELAYED-ADDRESS

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x0017: = REQUESTED-ADDRESS-FAMILY

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x0018: = EVEN-PORT

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x0019: = REQUESTED-TRANSPORT

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x001A: = DONT-FRAGMENT

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x0021: Reserved = (was TIMER-VAL)

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x0022: = RESERVATION-TOKEN

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TBD-CA: = ADDITIONAL-ADDRESS-FAMILY

> = ADDITIONAL-ADDRESS-ALL

> = ADDITIONAL-ADDRESS-ALLV4

> = ADDITIONAL-ADDRESS-ALLV6

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TBD-CA: = ADDRESS-ERROR-CODE

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TBD-CA: = ICMP

> 

> Actually, browsing through the draft for = ADDITIONAL-ADDRESS-FAMILY, very

> little text seems to be added for = generalization to=C2=A0 ADDITIONAL-ADDRESS-xxx.

> Almost everything applies to = ADDITIONAL-ADDRESS-xxx and can be reused.

> 

> ADDITIONAL-ADDRESS-ALL should be the default = for any modern TURN client.

> 

> Check! - We need this now.

> 

> Thanks,

> Karl

> 

>> -----Original = Message-----

>> From: Karl = Stahl [mailto:karl.stahl@ingate.= com]

>> Sent: = Sunday, March 4, 2018 10:36 PM

>> To: 'Marc = Petit-Huguenin' <petithug@acm.org>; Konda, Tirumaleswar = Reddy

>> <TirumaleswarReddy_Konda@M= cAfee.com>; tram@ietf.org<= span lang=3DEN-US>

>> = Subject: SV: [tram] Review of dual allocation in = TURNbis-11

>> 

>> Hi,

>> 

>> When we now have "dual = allocation" into this draft (I see on page 26: = "If

> the

>> client wishes to obtain one IPv6 and one = IPv4 relayed transport address

> then

>> it includes an ADDITIONAL-ADDRESS-FAMILY = transport address then it") can

>> we not generalize that further and allow = MORE THAN ONE relayed transport

>> address (of any family) in response to an = allocation?

>> 

>> I mean that a TURN server could have = several relay interfaces at different

> IP-

>> addresses into different networks - not = just the Internet, but also a VoIP

>> (higher quality) network e.g. by some = triple play service provider, an IMS

>> network or some branch office = network.

>> 

>> I think this is specifically important for = network provided/auto

> = discovered

>> turn servers = (application provided turn servers could instead just = list

> several

>> turn servers).

>> 

>> I saw someone snipped this about = "SINGLE relayed transport address per

>> allocation request"

>> > > https://tools.ietf.org/ht= ml/rfc6156#section-3

>> > > <snip>

>> > >

>> > >=C2=A0=C2=A0=C2=A0 TURN servers = allocate a single relayed transport address per

>> > >=C2=A0=C2=A0=C2=A0 allocation = request.=C2=A0 Therefore, Allocate requests cannot carry = more

>> > = >=C2=A0=C2=A0=C2=A0 than one REQUESTED-ADDRESS-FAMILY = attribute.=C2=A0 Consequently, a

>> client

>> > >=C2=A0=C2=A0=C2=A0 that wishes to = allocate more than one relayed transport address at

> a

>> > >=C2=A0=C2=A0=C2=A0 TURN server = (e.g., an IPv4 and an IPv6 address) needs to perform

>> > >=C2=A0=C2=A0=C2=A0 several = allocation requests (one allocation request per relayed

>> > >=C2=A0=C2=A0=C2=A0 transport = address).

>> > > = </snip>

>> 

>> but if that is remedied now, it seems like = a small step to generalize so

> = we can

>> get multiple = relayed transport addresses from one allocate request?

>> 

>> /Karl

> 

> 

> -----Ursprungligt = meddelande-----

> Fr=C3=A5n: = tram [mailto:tram-bounces@ietf.= org] F=C3=B6r Konda, Tirumaleswar Reddy

> Skickat: den 18 mars 2018 = 09:51

> Till: tram@ietf.org<= o:p>

> =C3=84mne: Re: [tram] I-D = Action: draft-ietf-tram-turnbis-15.txt

> 

> This revision addresses comments from Mark, = Karl and Noriyuki Torii.

> 

> -Tiru

> 

>> -----Original = Message-----

>> From: tram [mailto:tram-bounces@ietf.= org] On Behalf Of = internet-

>> drafts@ietf.org

>> Sent: Sunday, March 18, = 2018 8:43 AM

>> To: i-d-announce@ietf.org

>> Cc: tram@ietf.org<= o:p>

>> Subject: [tram] I-D = Action: draft-ietf-tram-turnbis-15.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.

>> 

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = Traversal Using Relays around NAT (TURN): Relay

> Extensions

>> to Session Traversal Utilities for NAT = (STUN)

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = Tirumaleswar Reddy

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alan Johnston

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Philip Matthews

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Jonathan Rosenberg

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = draft-ietf-tram-turnbis-15.txt

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = 84

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = 2018-03-18

>> 

>> Abstract:

>>=C2=A0=C2=A0=C2=A0 If a host is located = behind a NAT, then in certain situations it can

>>=C2=A0=C2=A0=C2=A0 be impossible for that = host to communicate directly with other hosts

>>=C2=A0=C2=A0=C2=A0 (peers).=C2=A0 In these = situations, it is necessary for the host to use

>>=C2=A0=C2=A0=C2=A0 the services of an = intermediate node that acts as a communication

>>=C2=A0=C2=A0=C2=A0 relay.=C2=A0 This = specification defines a protocol, called TURN = (Traversal

>>=C2=A0=C2=A0=C2=A0 Using Relays around = NAT), that allows the host to control the

>>=C2=A0=C2=A0=C2=A0 operation of the relay = and to exchange packets with its peers using

>>=C2=A0=C2=A0=C2=A0 the relay.=C2=A0 TURN = differs from some other relay control protocols in

>>=C2=A0=C2=A0=C2=A0 that it allows a client = to communicate with multiple peers using a

>>=C2=A0=C2=A0=C2=A0 single relay = address.

>> 

>>=C2=A0=C2=A0=C2=A0 The TURN protocol was = designed to be used as part of the ICE

>>=C2=A0=C2=A0=C2=A0 (Interactive = Connectivity Establishment) approach to NAT traversal,

>>=C2=A0=C2=A0=C2=A0 though it also can be = used without ICE.

>> 

>>=C2=A0=C2=A0=C2=A0 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/ht= ml/draft-ietf-tram-turnbis-15

>> https://datatracker.ietf.= org/doc/html/draft-ietf-tram-turnbis-15

>> 

>> A diff from the previous version is = available at:

>> <= span = style=3D'color:windowtext;text-decoration:none'>https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-tram-turnbis-15

>> 

>> 

>> 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/intern= et-drafts/

>> 

>> = _______________________________________________

>> tram mailing list

>> tram@ietf.org<= o:p>

>> https://www.ietf.org/mail= man/listinfo/tram

> 

> = _______________________________________________

> tram mailing list

> tram@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/tram

> 

> = _______________________________________________

> tram mailing list

> tram@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/tram

 

_______________________________________________=

tram mailing list

tram@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/tram

------=_NextPart_000_01B2_01D3CD06.E6A72D50-- From nobody Thu Apr 5 08:54: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 E188112D88D for ; Thu, 5 Apr 2018 08:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ingate.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 9F2hnh1FY1jY for ; Thu, 5 Apr 2018 08:54:13 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00061.outbound.protection.outlook.com [40.107.0.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9915412D87D for ; Thu, 5 Apr 2018 08:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ingate.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V4Mqg4126GSyCPSZVVRhooZCgr6JXdkyBn4GWhwRrMI=; b=mLa6jvHTjhZM5SvBuuI90px5BHeS11en8C2LaFNA2gTarkAu6w5b4xnEP72Lj4so9Pho/5AQmxdEqGfNNYfGc43gMxZfp0NevP+efYdkwK9NrtNEVbPB4sNSt+t/t1OBYEdfBNfvaiAqKnYH8ZuMbXJbNn485uvanzPtqFr+IRI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=karl@ingate.com; Received: from Kallei7 (90.229.133.175) by VI1PR01MB1837.eurprd01.prod.exchangelabs.com (2a01:111:e400:7bd8::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Thu, 5 Apr 2018 15:54:06 +0000 From: "Karl Stahl" To: "'Justin Uberti'" , "'Olle E. Johansson'" Cc: "'Brandon Williams'" , "'Simon Perreault'" , , References: <152136260256.18150.10551009018364033510@ietfa.amsl.com> <0e354f75-5ca9-07d2-9e63-2b9bc49fd4fe@akamai.com> <708D2731-0E8B-4AB8-B4C1-27C86573341D@edvina.net> In-Reply-To: Date: Thu, 5 Apr 2018 17:54:11 +0200 Message-ID: <01c701d3ccf6$58c430b0$0a4c9210$@stahl@ingate.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C8_01D3CD07.1C4D00B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdPLCRMhSo/inRkHSs6EKro3zRax5wB3SUlg Content-Language: sv X-Originating-IP: [90.229.133.175] X-ClientProxiedBy: AM0PR06CA0055.eurprd06.prod.outlook.com (2603:10a6:208:aa::32) To VI1PR01MB1837.eurprd01.prod.exchangelabs.com (2a01:111:e400:7bd8::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ee9b75d0-a2a4-488f-c0a8-08d59b0d76f9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:VI1PR01MB1837; X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1837; 3:fue3BbAKLM8ZN8YMd+/XpZLs9HHxvTvynvIxVS+RTLYeZkdl0GhVsxbwkXSoqxWrgoEsT7Ks4v0CxQfBw77w/E9X6LQRxwIJ9a0mFY9ZNyQR0z3MEprKWHm39lj+a5ur0PVrf6LFEIdveNIgh8AXgujd9YiU6AzO8efXk93EmkxsadkRXhnrAQq9vBXqitCT0O7p+M5/VZ0r/yUcxwKdkMiijkIXxovTVTcYC5D0K38dLatEVEWZNPwdJzxPNnzY; 25:YC5D403ae2+Arwi8aN1nGJ7VKbdV+cr2NFE97iGmwGj5jdwUZXD6BWGAgSYTMg550wHWvC0hIcc2MqznFevDFT28/99c4m3TioXJSdwlB9REpvEHRZcmKzkojeuuNRBYbjB1JRC4Y9Wt5I1Q87Q+Zl0YpddaaK+qYwgym0RDz+lpHZuwbsH9615sobjOwAyK6zqgJNhQ7Tc7wHl1gGdG8hr5dyU4ghsMF5R44PaprbW9Ho2rLP3/fCCdk4mKD8IqM1j+yOxli/KCw2ULP1kHZmfxit1g8cQPEz63oNtc4ZtbpCj8jVpyWVnde7A6pSjARhzk0HY7x0tLNW5UVTgoKw==; 31:pjleGQFXnYBmka9WaQFNwGtrfV+0nIPqb+CHBwkSnK/3wzRwW+ldArdqSqi6Yp8u8SBwRmFFQjYS5H1Zk96Nwh9iPR17gTC+HJkMLCtQULL+LUVz3WbtVMqD3+c+wsm1FXtBise8mrFx1AFefKMGrhzsX/pJhXtZcPBryPAJLdcziZ9/X631QMsoUICE5t6dqXDaNB43fR76uCwPaDrZNHhjf+5d+Pq7ayAT3IJRtGM= X-MS-TrafficTypeDiagnostic: VI1PR01MB1837: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(28532068793085)(158342451672863)(192374486261705)(211936372134217)(100405760836317)(21748063052155)(123452027830198); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(2016111802025)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6043046)(6072148)(201708071742011); SRVR:VI1PR01MB1837; BCL:0; PCL:0; RULEID:; SRVR:VI1PR01MB1837; X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1837; 4:hmV4ON+jEWCcNy2JTKkHEULrunXAC26/1P6HsDjK3EZMN4EwbAFGjzajJWRAv9E+hmPRzj64XItJF9+CeP7OALTyNSduKYoQKwtyT90IGhnWutB1disLJz1uB3OC83wqxyDRepVxLYqPd4xB6g082h1WG1bd6ZftVlYhZprnTx9vgeQdYJRb1YwOCVlmxoTAFI6GPedwcgLLWhn3ZTE4/Y2VkRMt6q/tf90bHIpfKy3jIYRlM4PQaundoum0V2WcB2g4j1saRaEkwndXJkEIfxg0l3S7XZ/KXzmAdx+Dywoclp8Rcyly36Cyy/CHN1aToTBEzNGQmWpaPnQFIiDxOuh5thPtzN7Nx6JfwqIGTeqgRLBrb3XHhMWpIXhKYkedJ8zx8c/zPHFUxa4VnTsHM3+rTEUe1NOdeOkZfaA7UztoRWTde1HJGsa7k7EPOf/lzgVOEYM2DmoYbPYEivr+nmytluZhQyFVNx4bjF5XqhAU12rTna7cHt+MMeTF3qsqLEo9BSleLOp+oT0zwEQipQ== X-Forefront-PRVS: 06339BAE63 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(39830400003)(396003)(366004)(346002)(199004)(189003)(377424004)(54906003)(105586002)(66066001)(476003)(4326008)(1857600001)(44736005)(93886005)(61296003)(7826002)(39060400002)(54896002)(478600001)(61793004)(53946003)(236005)(53936002)(6486002)(486006)(18717965001)(966005)(9686003)(7736002)(102836004)(6306002)(561944003)(186003)(96836002)(16526019)(36756003)(110136005)(26005)(316002)(16586007)(2906002)(606006)(106356001)(25786009)(6116002)(790700001)(386003)(6496006)(3846002)(956004)(8676002)(446003)(11346002)(84326002)(5660300001)(33964004)(53546011)(59450400001)(52116002)(76176011)(68736007)(97736004)(33896004)(84116003)(6666003)(1420700001)(14726001)(71636004)(50226002)(81166006)(81156014)(8936002)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR01MB1837; H:Kallei7; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: ingate.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjAxTUIxODM3OzIzOjRTQjhZK3VvRExLdzEvSEJYeC9zRVlQYm1I?= =?utf-8?B?WkpnZVhGcGo0U1hHd09vZ2dYRHgwcmNIYnM1UGVnRFVwdElZMXB5bU5YUjNr?= =?utf-8?B?cG8zL2liVXdKZG8zNTNVU1AzRUFCWndNL3dobWpYMjh6Q3dvMk5EV1FVdy9i?= =?utf-8?B?T1p4ak1HVUMwUXdRZnNLejV3dXhNdmUzbGV3QUlIN3YwZno4aVBiWmQvMGJ3?= =?utf-8?B?ZURDbU0yY24vc1R2MHM0cnloZG02OTBHUmJ5cFpoMU9uMlBDbGZCRmNCVlV1?= =?utf-8?B?UFhFUG9kMjhybVIvbC81SGdjT1BXK3dOZ2ZOUG5tOU4yb0tmWHlrc3U2MUVE?= =?utf-8?B?aFN3UytuMERLNDVuczdLYmRRZm1obXhQTkorTUpLYmpNNnJwTzNGdFFMR3Fi?= =?utf-8?B?Vmh5NTRzWlJpd3BHalJ0QUZpUG8yWE9JMENRZnBBM0Jxc2t2aFJJU0ZtSHJD?= =?utf-8?B?aFcwZWxQdGtvbnRHK0wwN2ZTRFlSbEpVQ2JRdWlVR2RnRklIY3cvc1c5dkU2?= =?utf-8?B?dVFiNFpzV1crL0s1dWszbTJNcmkyL2ZhbGNWMTZnMURhTU1abmpaUjRKUGV2?= =?utf-8?B?bzZwbzEzaU12eFZiY2lFNmRSY2dUcyt5MGZTa0grUVltUnpHN0h4SGI2S1dV?= =?utf-8?B?TzhKNFBGMklseXl6Z0FSVDB3RXBnbU94M1Z5eHJTd1BNTlljdWJNY240eUJT?= =?utf-8?B?NEZKRW9CQ3JrYUhpUlJUWjZQY3V5czFmM1dlRUpFYlpiN2hLVi9jSkJXMmpW?= =?utf-8?B?Y3BmbmtSRkxLQ0NOSHlQd0J6VjUrLzd6RWE5b2cxN1dwMkVWWlJ0TFNJYzd2?= =?utf-8?B?UUVsNFl6T3BBVGhpRDZJenltU0REVDdyblAzd3BIZ3drUXlybjV2UjJGMlEv?= =?utf-8?B?UFk3MXFYWUNlanhzOUpLRnM0YThCZDJnS01PL0ZubTc1ODdaS0M3UGwxTWFM?= =?utf-8?B?UVhaZnRvY05ZZEJKK0dlbmYyUWtjQVRIR0dIVXg4VWMrK2toY25DUURYNmVj?= =?utf-8?B?NHVPTmw1alF0b0IyMnV1THUvTVRocXkyRFJpdlNBajZrVHhvR2xMNk4vMHlv?= =?utf-8?B?dnpYc1MvczMreGdCYVFtNCtRVmtrSDlTMzRneW5iNEYreTR4aEU4QVh0RTRw?= =?utf-8?B?VnlTbXNIOEpCVjJrREIya2FYdlNUd3RxaW1GUmJmUEdGVStkQTI1U3RVZTZK?= =?utf-8?B?anQ3MVpBOGhKZXM2NUlGenFuMXlRSEZ0eVkwV3RmYStPQ09US2JHRkl6czVG?= =?utf-8?B?MFhadnl0Sk03YW1jck1TRlVVQ2xvd3Z6S3ptNk1CRlFPNUU4MGhZQjVqQlA3?= =?utf-8?B?N29WWHlGK2s4cnI0NTBBSHNCQ1lmL04yOTMxVUFEMTFoOFlvL1dXc2drYVhw?= =?utf-8?B?ZXlpSE1zYzE2SFVjeWZ4OHIxSHZyNGVkeWVTc25jWGw3STZ2WGZZcEoya2pw?= =?utf-8?B?cU1GNDVpZ09tenN4YlBMWU16NkJDV0x6MDVxU1FEdFRaekEydUt5YkFaTWs0?= =?utf-8?B?eHQ2cUxNUWoxeXJuSS9RRTJQanBNUXI4bStoS2Z6SWl0RzZ0MUMva0xKaWI0?= =?utf-8?B?cmIvMXlnSGhnOVZxMGlVSi8wc29LaUpCNm5NN040VkVhWXhOVllnVnhaY2FO?= =?utf-8?B?a3FXdk9JOGdEYWVrbEZUZU1NelJ6TW40Q0J5ZEN5VXZJdGhGT0tlY1E3bEk5?= =?utf-8?B?dGNyK3M4eVpIZGoxNFpwK3NHWGI0dlVxOHB3Mkw0NlRKOFU3NWsyWjh0b0VJ?= =?utf-8?B?NDl4RFFmVkp4Y0tCMmFmN2sxQUZ3Tnl1aTY3Vm9YdEVoZzhqTjFDekhaanho?= =?utf-8?B?b2xadWdvVmhMMnUvaVZzOThjTmFpbUpFN3dvZHRzZSt3bk9SNENoZlp3OU5Q?= =?utf-8?B?bG1hSmNPc2VrM3RmbDRRa1RKb0tDTkdrUEFwVVU1emFoT3dGcy9LbVdyTEVR?= =?utf-8?B?ODJqTDBhcnlpNkxvMDBOcWVjQko2RmhhQ0htb1laaERTYTl6ekFPSS82WmUr?= =?utf-8?B?bHZQZTNQYXVFbGNDaGZocnEvWk1NaUNRd2xPWFJQV3NjaTVMM0FwYjZVMmJL?= =?utf-8?B?Um9iL0FBZkd5bU1yZWlhMmtybTR3OHQ1OG4vYzIvWXhuM1JGU1owbGNXWkRW?= =?utf-8?B?VmlOZHFDKzhtdE5FOTJsdEFuU01WNncrRmRuek9oWTNmMG92clVQQ0N0OUdi?= =?utf-8?B?Z0RxUEtDL0R3RmMvZktLdFpkTnBGaWZ4YmdmVVRFZ0ZlVTFkdnNsYTZYRkdl?= =?utf-8?B?aC9tNEpFcHBKUjNwSTA5UVhhRUNnT05zdDJGZEUzSDBQWExsNnR5Zz09?= X-Microsoft-Antispam-Message-Info: HbyWNTDDBuRbfhgGrc4MV0mygLlkxHzcTNwZn2evxjuTxMo2+Rza8BnrW7MxdvEP6Cbky0/SZMUHyD2MnTD7n/+XjS/z71OlSG/yQPkXddAylQyaiW+sLM3cML2BA2jNIwvhzZL+SrUIse+B+O0SKeVnoeapJX4sNGgWHrgPT3JnnCuRv0bo9NOKN5Xz8TMX X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1837; 6:KQAN+6XdxZUvRBm1xJtIVPcf1ed/DF++iJr2qBNesrpv43lHr98ItVCyJDRkqdqvMsERcBQ/8/scC9RrV2jqtEU+RvH+BqPFZWadWwVSTwPgQM7eTW+Vg8Hsz/KANd1qT7zQmnso2UJKKZwQtoxR166ks3uwjZuG5u1nP4bByBY3FoLWJ3Yxcuo9Xpni9d/7AHUGuWZfKK4MA3rNz06iUEIurK9kwpRP1RSxjOSpPyNUwVSTL88YgN80iDDEM+bX62rjVq2JW5ecCewnxTfx+QVfaYMwXcd7i/Ltz+9Hd8j1tDkUKPdTaaQCn8JR5Na+TFeKlkXgy1BRRSrxABJ6sOhfjKsk6Le6Xyl6VxAykHqgTJ1ePLjXyAAe3E6P4aZgU54w3+FAF1y6wCjNjEcOmpQdlJEWN3rMDF8222PoCmU4ErThsMTF4udhi0BaeWbw4vvLPgqxs4U6qJpnG+By+Q==; 5:WuIphhuKe2OU8h+fVX3KGUqfX/1hd0uEI0YVCJaG8/OEM/qrlu5ZA5cVf4kmtbHVXVbvUr28bN++/JMHjTmuwCYn2HWOXGdNh25Srw86QpHFSNuwRRpUwsw3nM1lbriJxmUi786XQQzGtxR5RJrRjV4bZUGLLXI6w9YJUKrvKRo=; 24:u2Wwh7vn6PP4mtKN80BpBUzrVfUZPOefm2hqBV+EHYqKqqSoybhUImX2x85Aigmxxab813v+7IT7C+GozOkSCkBqYFVSdLnNs0BT3OGksmE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1837; 7:zn8wwgSnrplayuVAtb9QeXuZr0LAycaUHAHMIK3epC++TiYSbLCV/ocU92elGDDTyFjpsLPkoX3+iyG+29Bb/eAC+DYw5ZY9kHhwPCHi4zfWgVJ5URBCJlFcLqaYdY2zsi3cYiEdO0PpoP/4+Q7JWJqR2u5gqrBw8Jo2Nuj0ewsQVp7UrDikxn+4OuqFOmQ16Q7CkFKjeL7mRTaAuQEN1TeUIDHBRKcsc7wVgjNruiWm0NsS5ZfUVFxp5W45ckT3 X-OriginatorOrg: ingate.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2018 15:54:06.8252 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ee9b75d0-a2a4-488f-c0a8-08d59b0d76f9 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c3eda49a-3ed0-46c6-8a9e-d0d8ce3d2fae X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR01MB1837 Archived-At: Subject: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.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, 05 Apr 2018 15:54:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01C8_01D3CD07.1C4D00B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Justin> It's not clear to me why multiple addresses of the same family = are ever needed SIMPLY: Real-time media is not only over the public Internet In fact, most of today=E2=80=99s telephony VoIP goes over other networks = that the Internet. =20 Most SIP trunking into enterprise PBXs comes on higher quality pipes for = that telephony VoIP, and the large enterprises that block UDP access = from their LANs (and which the https://tools.ietf.org/html/rfc7478 Web = Real-Time Communication Use Cases and Requirements as well as your and = Benjamin=E2=80=99s = https://www.ietf.org/archive/id/draft-ietf-rtcweb-return-02.txt=20 have the aim of supporting) most often ALSO have a higher quality WANs = between their branch offices. There is big business putting VoIP over = those networks (today it is SIP based using SBCs, future will use WebRTC = and Network Provided Turn-servers. =20 And a third need is in even seen in home access routers: Those telephony = RJ11 FXS-ports you see on them, are typically connected to SPs VoIP = higher quality than Internet networks (maybe an IMS network). There is a = lot of policy based routing going in, especially with real-time media. =20 For doing that with ICE/TURN and network provided TURN server on the = LAN, the =E2=80=9CTURN Proxy=E2=80=9D as you call it, simply needs the = multiple Allocation. It is a simple and elegant solution (You would NOT = like the alternative of addressing several TURN servers (auto = discovered) on the LAN from the Client).=20 =20 Justin> and even if we supported this, how the client would be expected = to select between them Do you see problems with the approach of offering all and selecting the = first that works, just like Happy Eyeballs? =20 I don=E2=80=99t have SSODA background and not so much HTTPS proxy = background as you =E2=80=93 More from real-time communication with SIP = VoIP and arranging NAT/Firewall traversal using SBC (don=E2=80=99t like = that misused name on our products that are really SIP aware firewalls in = line with the MIDCOM work from the time before ICE/TURN/STUN) which may = be why we see different needs.=20 =20 I=E2=80=99m not saying anything of that SSODA is wrong or work wasted = =E2=80=93 on the contrary =E2=80=93 I want it generalized because we = need it!=20 =20 Olle, I also think there one day will (have to be) a separate document = that =E2=80=A6 clearly how network-provided TURN-servers is supposed to = work (there is more that should/could be done in there also), but now we = need have the base standards to support instead of hinder it, which was = one thing TRAM was supposed to achieve.. =20 Olle> security section of RFC 8155 =E2=80=A6 On the other hand, I = don=E2=80=99t really like how it was added to that RFC It was the other way around=E2=80=A6 The TRAM intent of what became = https://www.rfc-editor.org/rfc/pdfrfc/rfc8155.txt.pdf was (from mile = stone) =E2=80=9CTURN server discovery mechanism for enterprises and ISPs = to IESG=E2=80=9D that is Network Provided TURN server in local or access = network. =20 The intent was NOT Brandon=E2=80=99s Network Provided TURN servers that = are OUTSIDE the local or access network and it is very unfortunate that = https://www.rfc-editor.org/rfc/rfc8155.txt took the approach = =E2=80=9CThis document describes three discovery mechanisms, so as to = maximize the opportunity for discovery, based on the network in which = the TURN client finds itself.=E2=80=9D (We definitely don=E2=80=99t want = to find Brandon=E2=80=99s turn servers when trying to discover the very = private TURN server on the LAN =E2=80=93 unfortunately making RFC 8155 = more or less useless for its intended purpose (under my protest). =20 /Karl Fr=C3=A5n: Justin Uberti [mailto:juberti@google.com]=20 Skickat: den 3 april 2018 07:03 Till: Olle E. Johansson Kopia: Brandon Williams; Simon Perreault; = TirumaleswarReddy_Konda@mcafee.com; tram@ietf.org; Karl Stahl =C3=84mne: Re: [tram] Multiple allocations SV: I-D Action: = draft-ietf-tram-turnbis-15.txt =20 I spent time with Pal and others coming up with the initial dual = allocation concept (SSODA) and there are clear reasons for this approach = (as discussed in the intro of the original SSODA doc). =20 It's not clear to me why multiple addresses of the same family are ever = needed though, and even if we supported this, how the client would be = expected to select between them. It seems like a large expansion of = scope beyond the goals of SSODA. =20 On Mon, Apr 2, 2018 at 11:47 AM Olle E. Johansson = wrote: Hi! Well, since Network-provided servers was added to the security section = of RFC 8155, I kind of think it=E2=80=99s now in scope for everything TURN and from that standpoint I do understand Karl=E2=80=99s = objections. On the other hand, I don=E2=80=99t really like how it was added to that = RFC and like the idea of a separate document that clears this mess up and explains clearly how network-provided = TURN-servers is supposed to work, the requirements and additions to the TURN protocol. The problem with that is that implementors may think it=E2=80=99s just = an add-on and not implement it in the TURN client implementations, which would be harmful in the long run. Question: Will adding operations or modifying existing ones in a new = document make it a mandatory part of the TURN protocol, an update to the TURN RFC (turnbis as an RFC = that is)? /O > On 2 Apr 2018, at 18:46, Brandon Williams = wrote: > > Karl, > > There is no WG decision to hinder this, simply a disagreement about = approach. > > Some of us (the editors in particular) have been working on the = turnbis draft for quite some time. It went into WGLC several months ago = and it is already well behind the originally agreed schedule in the = charter. > > Considering the fact that this is not something that was ever called = out previously, we are only questioning why it has suddenly become = critical to expand the scope of turnbis and thus delay publishing even = further. > > If there were already a draft that explains the rationale, use cases, = and protocol changes, it would be easier to assess the impact and = consider inclusion. This was the path followed by a few other new = capabilities that were eventually rolled directly into turnbis. > > If the WG came to the conclusion that we should not delay turnbis any = further but instead should advance the capability as a new RFC = candidate, we would already be in a good position to that if we had a = draft in hand. If the WG decided to include this in turnbis, we would = already have text available. > > IOW, I am only resisting the idea of expanding the scope of turnbis = without WG consensus to do so; I am not resisting your proposal itself. = The suggestion that you take the time to write down your idea in I-D = format seems like a good way for you to drive the required WG = discussion. > > --Brandon > > On 03/22/2018 05:17 PM, Karl Stahl wrote: >> No and this draft cannot be approved without the generalization I = have pointed out. >> I really don=E2=80=99t understand why we are having this resistance. >> Already the second paragraph of the Abstract states: >> 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. >> And further in the Introduction >> TURN was designed as one piece in the larger ICE approach to NAT >> traversal. Implementors of TURN are *_urged_* to investigate ICE = and >> seriously consider using it for their application. >> ** >> I cannot imagine that there is some WG decision to hinder ICE usage = for network provided TURN servers EXCEPT FOR EXACTLY BRANDON=E2=80=99S = NETWORK. >> For now I refrain from writing/debating more =E2=80=93 which would = override the effort of what is required to generalize as asked. >> Please be happy that most of the dual allocation work done, can be = reused to fulfill the generalization. >> Tiru and Brandon are encouraged to read the TRAM charter =E2=80=A6 >> /Karl >> *Fr=C3=A5n:*Simon Perreault [mailto:sperreault@jive.com] >> *Skickat:* den 21 mars 2018 18:13 >> *Till:* Brandon Williams >> *Kopia:* Konda, Tirumaleswar Reddy; Olle E. Johansson; Karl Stahl; = tram@ietf.org >> *=C3=84mne:* Re: [tram] Multiple allocations SV: I-D Action: = draft-ietf-tram-turnbis-15.txt >> 2018-03-21 17:05 GMT+00:00 Brandon Williams = >: >> Chairs, Any suggestions on approach? >> The proposal on the table is for Karl+Olle to write their idea into a = new draft. >> Karl+Olle, can you guys live with that? >> Simon >> ********************** >> Let me explain more clearly why multiple allocations is needed: >> ICE is about finding all/many paths for the media, e.g. with the help = of >> TURN servers. >> Those paths are not over ONE IPv4 network, over ONE IPv6 network or = EXACTLY >> ONE OF EACH. >> If fact, it is more common that you have several IPv4 networks paths. >> Now that we have network provided TURN servers, you only ask for = Allocation >> once (contrary to application provided TURN servers, where you can be >> directed to Allocate several times.) and thus we need all relay = addresses in >> one allocation request. >> Wasn't that the reason dual allocation was requested? The need for = multiple >> allocation is stronger! >> Please address this, e.g. like below (seems you are almost there). >> /Karl >> ******************* Previous ******************* >> Allowing a turn allocation to return multiple relayed transport = addresses, >> beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on = different >> interfaces/network segments), seems like very small step now when the = dual >> allocation was put in place in this draft. We certainly need it (some >> reasons below) if TURN is going to be used where needed and we cannot = wait >> for any additional draft. >> Seems like it is sufficient to extent this table (found in draft 14) = with 3 >> new values (as shown): >> 16. STUN Attributes >> This STUN extension defines the following attributes: >> 0x000C: CHANNEL-NUMBER >> 0x000D: LIFETIME >> 0x0010: Reserved (was BANDWIDTH) >> 0x0012: XOR-PEER-ADDRESS >> 0x0013: DATA >> 0x0016: XOR-RELAYED-ADDRESS >> 0x0017: REQUESTED-ADDRESS-FAMILY >> 0x0018: EVEN-PORT >> 0x0019: REQUESTED-TRANSPORT >> 0x001A: DONT-FRAGMENT >> 0x0021: Reserved (was TIMER-VAL) >> 0x0022: RESERVATION-TOKEN >> TBD-CA: ADDITIONAL-ADDRESS-FAMILY >> ADDITIONAL-ADDRESS-ALL >> ADDITIONAL-ADDRESS-ALLV4 >> ADDITIONAL-ADDRESS-ALLV6 >> TBD-CA: ADDRESS-ERROR-CODE >> TBD-CA: ICMP >> Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, = very >> little text seems to be added for generalization to = ADDITIONAL-ADDRESS-xxx. >> Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be = reused. >> ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN = client. >> Check! - We need this now. >> Thanks, >> Karl > > -- > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. > > _______________________________________________ > 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 ------=_NextPart_000_01C8_01D3CD07.1C4D00B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Ju= stin> It's not clear to me why multiple = addresses of the same family are ever needed

SI= MPLY: Real-time media is not only over the public = Internet

In= fact, most of today=E2=80=99s telephony VoIP goes over other networks = that the Internet.

 

Mo= st SIP trunking into enterprise PBXs comes on higher quality pipes for = that telephony VoIP, and the large enterprises that=C2=A0 block UDP = access from their LANs (and which the https://tools.ietf.org/html/= rfc7478 Web Real-Time Communication Use Cases and Requirements = as= well as your and Benjamin=E2=80=99s=C2=A0 = https://www.ietf.org/archive/id/draft-ietf-rtcweb-return-02.txt =

ha= ve the aim of supporting) most often ALSO have a higher quality WANs = between their branch offices. There is big business putting VoIP over = those networks (today it is SIP based using SBCs, future will use WebRTC = and Network Provided Turn-servers.

 

An= d a third need is in even seen in home access routers: Those telephony = RJ11 FXS-ports you see on them, are typically connected to SPs VoIP = higher quality than Internet networks (maybe an IMS network). There is a = lot of policy based routing going in, especially with real-time = media.

 

Fo= r doing that with ICE/TURN and network provided TURN server on the LAN, = the =E2=80=9CTURN Proxy=E2=80=9D as you call it, simply needs the = multiple Allocation. It is a simple and elegant solution (You would NOT = like the alternative of addressing several TURN servers (auto = discovered) on the LAN from the Client).

 

Ju= stin> and even if we supported this, how = the client would be expected to select between them

Do= you see problems with the approach of offering all and selecting the = first that works, just like Happy Eyeballs?

 

I = don=E2=80=99t have SSODA background and not so much HTTPS proxy = background as you =E2=80=93 More from real-time communication with SIP = VoIP and arranging=C2=A0 NAT/Firewall traversal using SBC (don=E2=80=99t = like that misused name on our products that are really SIP aware = firewalls in line with the MIDCOM work from the time before = ICE/TURN/STUN) which may be why we see different needs. =

 

I=E2= =80=99m not saying anything of that SSODA is wrong or work wasted = =E2=80=93 on the contrary =E2=80=93 I want it generalized because we = need it!

 

Ol= le, I also think there one day will (have to be) a separate document that =E2=80=A6 clearly how = network-provided TURN-servers is supposed to work (th= ere is more that should/could be done in there also), but now we need = have the base standards to support instead of hinder it, which was one = thing TRAM was supposed to achieve..

 

Ol= le> security section of RFC 8155 =E2=80=A6 = On the other hand, I don=E2=80=99t really like how it was added to that = RFC

It= was the other way around=E2=80=A6

Th= e TRAM intent of what became https://ww= w.rfc-editor.org/rfc/pdfrfc/rfc8155.txt.pdf =C2= =A0was (from mile stone) =E2=80=9CTURN server discovery mechanism for = enterprises and ISPs to IESG=E2=80=9D that is Network Provided TURN = server in local or access network.

 

Th= e intent was NOT Brandon=E2=80=99s Network Provided TURN servers that = are OUTSIDE the local or access network and it is very unfortunate that = https://www.rfc-edito= r.org/rfc/rfc8155.txt took the approach =E2=80=9CThis document = describes three discovery mechanisms, so as to maximize the opportunity = for discovery, based on the network in which the TURN client finds = itself.=E2=80=9D (We definitely don=E2=80=99t want to find = Brandon=E2=80=99s turn servers when trying to discover the very private = TURN server on the LAN =E2=80=93 unfortunately making RFC 8155 more or = less useless for its intended purpose (under my = protest).

 

/K= arl

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com]
Skickat: den 3 april 2018 = 07:03
Till: Olle E. Johansson
Kopia: Brandon = Williams; Simon Perreault; TirumaleswarReddy_Konda@mcafee.com; = tram@ietf.org; Karl Stahl
=C3=84mne: Re: [tram] Multiple = allocations SV: I-D Action: = draft-ietf-tram-turnbis-15.txt

 

I spent time with Pal and others coming up with the = initial dual allocation concept (SSODA) and there are clear reasons for = this approach (as discussed in the intro of the original SSODA = doc).

 

It's not clear to me why multiple addresses of the = same family are ever needed though, and even if we supported this, how = the client would be expected to select between them. It seems like a = large expansion of scope beyond the goals of = SSODA.

 

On = Mon, Apr 2, 2018 at 11:47 AM Olle E. Johansson <oej@edvina.net> = wrote:

Hi!

Well, since Network-provided servers was = added to the security section of RFC 8155, I kind of think it=E2=80=99s = now in scope for
everything TURN and from that standpoint I do = understand Karl=E2=80=99s objections.

On the other hand, I = don=E2=80=99t really like how it was added to that RFC and like the idea = of a separate document that
clears this mess up and explains clearly = how network-provided TURN-servers is supposed to work, the = requirements
and additions to the TURN protocol.

The problem = with that is that implementors may think it=E2=80=99s just an add-on and = not implement it in the TURN client
implementations, which would be = harmful in the long run.

Question: Will adding operations or = modifying existing ones in a new document make it a mandatory
part of = the TURN protocol, an update to the TURN RFC (turnbis as an RFC that = is)?

/O




> On 2 Apr 2018, at 18:46, Brandon = Williams <brandon.williams@akamai.com> = wrote:
>
> Karl,
>
> There is no WG decision to = hinder this, simply a disagreement about approach.
>
> Some = of us (the editors in particular) have been working on the turnbis draft = for quite some time. It went into WGLC several months ago and it is = already well behind the originally agreed schedule in the = charter.
>
> Considering the fact that this is not something = that was ever called out previously, we are only questioning why it has = suddenly become critical to expand the scope of turnbis and thus delay = publishing even further.
>
> If there were already a draft = that explains the rationale, use cases, and protocol changes, it would = be easier to assess the impact and consider inclusion. This was the path = followed by a few other new capabilities that were eventually rolled = directly into turnbis.
>
> If the WG came to the conclusion = that we should not delay turnbis any further but instead should advance = the capability as a new RFC candidate, we would already be in a good = position to that if we had a draft in hand. If the WG decided to include = this in turnbis, we would already have text available.
>
> = IOW, I am only resisting the idea of expanding the scope of turnbis = without WG consensus to do so; I am not resisting your proposal itself. = The suggestion that you take the time to write down your idea in I-D = format seems like a good way for you to drive the required WG = discussion.
>
> --Brandon
>
> On 03/22/2018 = 05:17 PM, Karl Stahl wrote:
>> No and this draft cannot be = approved without the generalization I have pointed out.
>> I = really don=E2=80=99t understand why we are having this = resistance.
>> Already the second paragraph of the Abstract = states:
>> 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.
>> And further in the = Introduction
>> TURN was designed as one piece in the larger = ICE approach to NAT
>>    traversal.  = Implementors of TURN are *_urged_* to investigate ICE = and
>>    seriously consider using it for their = application.
>> **
>> I cannot imagine that there is = some WG decision to hinder ICE usage for network provided TURN servers = EXCEPT FOR EXACTLY BRANDON=E2=80=99S NETWORK.
>> For now I = refrain from writing/debating more =E2=80=93 which would override the = effort of what is required to generalize as asked.
>> Please be = happy that most of the dual allocation work done, can be reused to = fulfill the generalization.
>> Tiru and Brandon are encouraged = to read the TRAM charter =E2=80=A6
>> /Karl
>> = *Fr=C3=A5n:*Simon Perreault [mailto:sperreault@jive.com]
>> *Skickat:* den 21 = mars 2018 18:13
>> *Till:* Brandon Williams
>> = *Kopia:* Konda, Tirumaleswar Reddy; Olle E. Johansson; Karl Stahl; tram@ietf.org
>> *=C3=84mne:* Re: [tram] = Multiple allocations SV: I-D Action: = draft-ietf-tram-turnbis-15.txt
>> 2018-03-21 17:05 GMT+00:00 = Brandon Williams <brandon.williams@akamai.com <mailto:brandon.williams@akamai.com>>:
>> = Chairs, Any suggestions on approach?
>> The proposal on the = table is for Karl+Olle to write their idea into a new draft.
>> = Karl+Olle, can you guys live with that?
>> Simon
>> = **********************
>> Let me explain more clearly why = multiple allocations is needed:
>> ICE is about finding = all/many paths for the media, e.g. with the help of
>> TURN = servers.
>> Those paths are not over ONE IPv4 network, over ONE = IPv6 network or EXACTLY
>> ONE OF EACH.
>> If fact, it = is more common that you have several IPv4 networks paths.
>> = Now that we have network provided TURN servers, you only ask for = Allocation
>> once (contrary to application provided TURN = servers, where you can be
>> directed to Allocate several = times.) and thus we need all relay addresses in
>> one = allocation request.
>> Wasn't that the reason dual allocation = was requested? The need for multiple
>> allocation is = stronger!
>> Please address this, e.g. like below (seems you = are almost there).
>> /Karl
>> ******************* = Previous *******************
>> Allowing a turn allocation to = return multiple relayed transport addresses,
>> beyond ONE IPv4 = and ONE IPv6 (which may sit on the same or on different
>> = interfaces/network segments), seems like very small step now when the = dual
>> allocation was put in place in this draft. We certainly = need it (some
>> reasons below) if TURN is going to be used = where needed and we cannot wait
>> for any additional = draft.
>> Seems like it is sufficient to extent this table = (found in draft 14) with 3
>> new values (as = shown):
>> 16.  STUN Attributes
>>    = This STUN extension defines the following attributes:
>>  =     0x000C: CHANNEL-NUMBER
>>      = 0x000D: LIFETIME
>>      0x0010: Reserved (was = BANDWIDTH)
>>      0x0012: = XOR-PEER-ADDRESS
>>      0x0013: = DATA
>>      0x0016: = XOR-RELAYED-ADDRESS
>>      0x0017: = REQUESTED-ADDRESS-FAMILY
>>      0x0018: = EVEN-PORT
>>      0x0019: = REQUESTED-TRANSPORT
>>      0x001A: = DONT-FRAGMENT
>>      0x0021: Reserved (was = TIMER-VAL)
>>      0x0022: = RESERVATION-TOKEN
>>      TBD-CA: = ADDITIONAL-ADDRESS-FAMILY
>> ADDITIONAL-ADDRESS-ALL
>> = ADDITIONAL-ADDRESS-ALLV4
>> = ADDITIONAL-ADDRESS-ALLV6
>>      TBD-CA: = ADDRESS-ERROR-CODE
>>      TBD-CA: = ICMP
>> Actually, browsing through the draft for = ADDITIONAL-ADDRESS-FAMILY, very
>> little text seems to be = added for generalization to  ADDITIONAL-ADDRESS-xxx.
>> = Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be = reused.
>> ADDITIONAL-ADDRESS-ALL should be the default for any = modern TURN client.
>> Check! - We need this now.
>> = Thanks,
>> Karl
>
> --
> Brandon Williams; = Chief Architect
> Cloud Networking; Akamai Technologies = Inc.
>
> = _______________________________________________
> 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

------=_NextPart_000_01C8_01D3CD07.1C4D00B0-- From nobody Sat Apr 7 00:17:36 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 038FC129C56 for ; Sat, 7 Apr 2018 00:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, 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 tliqNKIxaxE3 for ; Sat, 7 Apr 2018 00:17:32 -0700 (PDT) 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 93CAE126BF6 for ; Sat, 7 Apr 2018 00:17:32 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1523085441; 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-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=e38ruQgAIhtwXY9/R4Wmt6IMJIm1FjSTOJ3RDT sxFnM=; b=D7BVrkn5OOa0+T1KGIrRmV/pqsi5H0rqITnkEcgQ 5b0MOkX086+p8fwVbb/xGjS/VZG+XfmmnwmUwbA0jLbHD1v8cp V+BTI989JylKjG2KsUBoTha5RKhnNIENUeeG2sBiE7iV7H395e g1SsvZoaW33uqZqQrPTRfXYaWBjtB9Y= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0d51_65bf_f7a07a77_80a2_4dc5_a079_0fa0517fcc1f; Sat, 07 Apr 2018 02:17:20 -0500 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 7 Apr 2018 01:17:19 -0600 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 7 Apr 2018 01:17:18 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sat, 7 Apr 2018 01:17:19 -0600 Received: from NAM01-SN1-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; Sat, 7 Apr 2018 01:17:17 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1490.namprd16.prod.outlook.com (10.172.207.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Sat, 7 Apr 2018 07:17:17 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Sat, 7 Apr 2018 07:17:17 +0000 From: "Konda, Tirumaleswar Reddy" To: Brandon Williams , Justin Uberti , Simon Perreault CC: Nils Ohlmeier , "Cullen Jennings (fluffy)" , Eric Rescorla , "tram@ietf.org" Thread-Topic: [tram] Allow TURN to forward inbound connectivity checks without permission Thread-Index: AQHTv3BE7H+lEDCzy0aE6LgkPsBdZKPYCNMAgAAflQCAAL9dgIAAUh+AgAAAqKCAEcv2gIABL1IAgABXjQCAATFfAIAHQsSw Date: Sat, 7 Apr 2018 07:17:17 +0000 Message-ID: References: <8d57a9e5-5697-38f5-1b85-bf55930c6461@akamai.com> <59a6378a-38ac-3168-e93e-d3e395122ae5@akamai.com> In-Reply-To: <59a6378a-38ac-3168-e93e-d3e395122ae5@akamai.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: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1490; 7:6cY1sLWNOxs4i7aAKuAl2BHifmfH8x8PlW15KM0N4knu0CS0qFC/p3iIFmXmFA5+zQ2HqwyI2GhRX8q6FmwdOCUajlKw4WRjUIBGXMMBaeCKlWyDKZs6DjluMRJYHuA6UonB9J2fpUHwtG8vl85kCoesWGsW2489N+IbP5oKP3Lkz9f/5NNOp4Y/ToYkokfKvVkeH6miXVNrW4ve6ZKFQ4xCdS6Lrc9JZIXBSQbiOmWDQaWmwLhAmVMKsrQTm/on x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 09e6f097-4f15-4f7e-610e-08d59c579837 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1490; x-ms-traffictypediagnostic: BN6PR16MB1490: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(95692535739014)(153496737603132)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR16MB1490; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1490; x-forefront-prvs: 0635D5275E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(346002)(376002)(366004)(396003)(32952001)(377424004)(13464003)(57704003)(199004)(189003)(6246003)(316002)(2906002)(97736004)(9686003)(80792005)(229853002)(3280700002)(7696005)(5660300001)(6436002)(476003)(446003)(7736002)(11346002)(53546011)(6506007)(76176011)(186003)(74316002)(55016002)(66066001)(86362001)(14454004)(3660700001)(3846002)(99286004)(6116002)(59450400001)(93886005)(478600001)(26005)(105586002)(25786009)(4326008)(72206003)(81166006)(33656002)(53936002)(5250100002)(68736007)(81156014)(106356001)(54906003)(561944003)(305945005)(102836004)(486006)(2900100001)(8676002)(8936002)(110136005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1490; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GENa40lmQRm+vRmaNf1fVmRPugn/toCFcH9i0YA1kmMDpZq608nfML8YsjVtxHiAcrxZgptCe5YGeCgJ/acNUQzGqGhIFMmSSQPhQSOJEk2cjrVTamNk6pLBRfGlUhmjKp5Ja3zJah3hFxuNetq1oY/f+lb6yUcd5tfHq0WeKcAsw2vx0mJ6hDLH4sE2HMahtcBypMMZvzMuIMg6nG317vB9V4LHeDWWs3dZXJh1bl5rAAqrlqpMQ3xzL4DaaWRwBRz0n7UPF54Snd+LsowAXX849crnRaIRGCgxrFkj+DVgOJlPGaRq2siTJCGkJl2Hj/omxmXCYMICJ28IUoNQhJH1Wj3zriyaKHg+vd5gJrqZnq0KOCwV7kYwF+i3ereJB6LfrMEclFTE4cLmc6jC8BQGpznh17l2s0o058x87Uk= 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: 09e6f097-4f15-4f7e-610e-08d59c579837 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2018 07:17:17.1646 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1490 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 <6259> : inlines <6554> : streams <1783437> : uri <2621856> Archived-At: Subject: Re: [tram] Allow TURN to forward inbound connectivity checks without permission 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: Sat, 07 Apr 2018 07:17:35 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBNb25kYXksIEFwcmls IDIsIDIwMTggOTo1MyBQTQ0KPiBUbzogSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29t PjsgU2ltb24gUGVycmVhdWx0IDxzcGVycmVhdWx0QGppdmUuY29tPg0KPiBDYzogS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47DQo+ IE5pbHMgT2hsbWVpZXIgPG5vaGxtZWllckBtb3ppbGxhLmNvbT47IEN1bGxlbiBKZW5uaW5ncyAo Zmx1ZmZ5KQ0KPiA8Zmx1ZmZ5QGNpc2NvLmNvbT47IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNv bT47IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0cmFtXSBBbGxvdyBUVVJOIHRvIGZv cndhcmQgaW5ib3VuZCBjb25uZWN0aXZpdHkgY2hlY2tzIHdpdGhvdXQNCj4gcGVybWlzc2lvbg0K PiANCj4gQWdyZWVkLg0KPiANCj4gRGlmZmVyZW50IG5ldHdvcmtzIHdpbGwgcmVxdWlyZSBkaWZm ZXJlbnQgYWNjZXNzIGNvbnRyb2xzLiBTb21lIHdpbGwgYmUgZmluZSB3aXRoDQo+IGxldHRpbmcg YW55dGhpbmcgdGhyb3VnaC4gU29tZSB3aWxsIGJlIGZpbmUgd2l0aCBsZXR0aW5nIGFueXRoaW5n IHRocm91Z2ggYXMgbG9uZw0KPiBhcyBpdCBsb29rcyBsaWtlIFNUVU4uIEFuZCBzb21lIHdpbGwg d2FudCB0byBoYXZlIHRoZSB0aWdodGVyIGNvbnRyb2xzIHRoZXkgZ2V0DQo+IGZyb20gZXhpc3Rp bmcgbWV0aG9kcy4NCj4gDQo+IFByb3ZpZGluZyBmbGV4aWJpbGl0eSB3aXRoIGEgZGlzY3Vzc2lv biBvZiB0aGUgdHJhZGUtb2ZmcyBzZWVtcyBsaWtlIHRoZSByaWdodA0KPiBhcHByb2FjaCB0byBt ZSB0b28uDQo+IA0KPiBUaGUgdWZyYWcgbWV0aG9kIHdhcyBpbnRlbmRlZCBtb3JlIHRvIHByb3Rl Y3QgdGhlIGNsaWVudCBieSBnaXZpbmcgc29tZQ0KPiBjb250cm9sIG92ZXIgd2hhdCdzIGFsbG93 ZWQgdGhyb3VnaCB3aGlsZSBvcGVuaW5nIGl0IHVwIGEgYml0IG1vcmUuDQo+IE5laXRoZXIgdGhh dCBub3IgY2hlY2tpbmcgZm9yIFNUVU4gZnJhbWluZyBwcm90ZWN0cyB0aGUgcmVsYXkgb3IgbmV0 d29yayBmcm9tDQo+IGEgZGVkaWNhdGVkIHVzZXIgd2hvIHJlYWxseSB3YW50cyB0byBjcmVhdGUg YSBuZXcgc2VydmljZSwgYnV0IGJvdGggcHJvdGVjdA0KPiBhZ2FpbnN0IHRoZSBzaW1wbGVzdCBt aXN1c2VzLg0KDQpBZ3JlZWQsIHdlIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCB0byBleHBsYWluIHRo ZSBkaXNjdXNzZWQgcG9pbnRzLg0KDQotVGlydQ0KDQo+IA0KPiAtLUJyYW5kb24NCj4gDQo+IE9u IDA0LzAxLzIwMTggMDY6MDkgUE0sIEp1c3RpbiBVYmVydGkgd3JvdGU6DQo+ID4NCj4gPg0KPiA+ IE9uIFN1biwgQXByIDEsIDIwMTggYXQgOTo1NiBBTSBTaW1vbiBQZXJyZWF1bHQgPHNwZXJyZWF1 bHRAaml2ZS5jb20NCj4gPiA8bWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5jb20+PiB3cm90ZToNCj4g Pg0KPiA+ICAgICAyMDE4LTAzLTMxIDE4OjUwIEdNVC0wNDowMCBKdXN0aW4gVWJlcnRpIDxqdWJl cnRpQGdvb2dsZS5jb20NCj4gPiAgICAgPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+PjoNCj4g Pg0KPiA+ICAgICAgICAgQXMgQnJhbmRvbiBzYXlzLCB0aGUgdWZyYWcvcHdkIGluZm8gY291bGQg YmUgcG9zdGVkIGFsb25nIHdpdGgNCj4gPiAgICAgICAgIHRoZSBhZGRyZXNzIG9mIHRoZSBzZXJ2 ZXIsIHNvIHdoaWxlIHRoaXMgcmFpc2VzIHRoZSBiYXIsIGl0DQo+ID4gICAgICAgICBkb2Vzbid0 IHNvbHZlIHRoZSBwcm9ibGVtLg0KPiA+DQo+ID4gICAgICAgICBJIGFncmVlIHdpdGggQnJhbmRv biB0aGF0IHRoZSBvbmx5IHJlYXNvbmFibGUgd2F5IHRvIGNvbXBsZXRlbHkNCj4gPiAgICAgICAg IGNvbnRhaW4gdGhpcyBpcyBzb21lIHNvcnQgb2Ygc2VydmVyIHBvbGljeSwgZS5nLiwgc29tZSB0 aW1lDQo+ID4gICAgICAgICB3aW5kb3cgb3Igc2Vzc2lvbiBjb3VudCBhZnRlciB3aGljaCB0aGUg cGVybWlzc2lvbiBieXBhc3MNCj4gPiAgICAgICAgIGV4cGlyZXMsIG1lYW5pbmcgdGhhdCBzb21l b25lIHJ1bm5pbmcgYSBzZXJ2ZXIgd291bGQgaGF2ZSB0byBiZQ0KPiA+ICAgICAgICAgY29udGlu dWFsbHkgcmVxdWVzdGluZyBuZXcgYWxsb2NhdGlvbnMgYW5kIHBvc3RpbmcgdGhlaXINCj4gPiAg ICAgICAgIGFkZHJlc3MvY3JlZGVudGlhbHMuDQo+ID4NCj4gPg0KPiA+ICAgICBEbyB3ZSBuZWVk IHRvIGNvbXBsZXRlbHkgY29udGFpbiB0aGlzPyBJcyB0aGVyZSBhY3R1YWxseSBhIHByb2JsZW0N Cj4gPiAgICAgd2l0aCB0aGUgcHJvcG9zYWw/DQo+ID4NCj4gPiAgICAgQWxsb3dpbmcgU1RVTiBp biBhbGxvd3Mgc29tZW9uZSB0byBydW4gYSBzZXJ2ZXIgaWYgYW5kIG9ubHkgaWYgdGhlDQo+ID4g ICAgIHByb3RvY29sIG1hc3F1ZXJhZGVzIGFzIFNUVU4uIEl0IGRvZXNuJ3QgYWxsb3cgYSB1c2Vy IHRvIHJ1biBhbg0KPiA+ICAgICBhcmJpdHJhcnkgc2VydmVyLiBGb3IgdGhpcyB0byBiZSBleHBs b2l0YWJsZSwgdGhlIHVzZXIgd291bGQgYWxzbw0KPiA+ICAgICBuZWVkIHRvIGNvbnRyb2wgdGhl IGNsaWVudHMgaW4gc29tZSB3YXkuDQo+ID4NCj4gPiAgICAgSSBjYW4ndCB0aGluayBvZiBhIHdh eSB0aGlzIGNvdWxkIGJlIGV4cGxvaXRlZCBwcmFjdGljYWxseS4gTWF5YmUgSQ0KPiA+ICAgICBs YWNrIGltYWdpbmF0aW9uPw0KPiA+DQo+ID4NCj4gPiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgZmF0 YWwgdG8gdGhlIHByb3Bvc2FsLiBJIGp1c3QgdGhpbmsgdGhhdCB3ZSBuZWVkDQo+ID4gdG8gYmUg dXAgZnJvbnQgdGhhdCB0aGlzIGlzIGEgcG90ZW50aWFsIGxvb3Bob2xlLCBhbmQgaGF2ZSBzb21l DQo+ID4gZXhwbGljaXQgZGlzY3Vzc2lvbiBpbiB0aGUgZG9jdW1lbnQgb2YgaG93IG9uZSBtaWdo dCBzb2x2ZSB0aGlzDQo+ID4gcHJvYmxlbSBzaG91bGQgaXQgYmVjb21lIG5lY2Vzc2FyeSAoZS5n Liwgd2l0aCBzZXJ2ZXIgcG9saWN5KS4NCg0K From nobody Thu Apr 12 04:41:20 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 1467F126C19 for ; Thu, 12 Apr 2018 04:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.71 X-Spam-Level: X-Spam-Status: No, score=-17.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=logmein.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 uqpnN5ua6WAq for ; Thu, 12 Apr 2018 04:41:17 -0700 (PDT) Received: from mx0b-001a0901.pphosted.com (mx0b-001a0901.pphosted.com [67.231.152.111]) (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 4D81B1200C1 for ; Thu, 12 Apr 2018 04:41:17 -0700 (PDT) Received: from pps.filterd (m0074900.ppops.net [127.0.0.1]) by mx0b-001a0901.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3CBcRf8030694 for ; Thu, 12 Apr 2018 07:41:16 -0400 Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0182.outbound.protection.outlook.com [216.32.180.182]) by mx0b-001a0901.pphosted.com with ESMTP id 2h9k9atw2g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 12 Apr 2018 07:41:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=logmein.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Kh1Hjow+lD8ufatLdoUWbVOEaAWJVF0MP2zDK9EhiL0=; b=bnss+DDgKFfiumuAKj5+OIW071iYlLRoocJu3w2LxPCCBsrcGm5iRwsQAkIDHpx+roYLLRdiFnpXlqGU9l3A3fKTu0j6+FGXKLT9o0pA2hl9Y5yUa5HJ7mgWpkI/bBJyHsfs1FzwUWFjnRBtGsIyzBQFurQzIIxQKpZ90X63RTs= Received: from DM3PR15MB0765.namprd15.prod.outlook.com (10.164.201.5) by DM3PR15MB1036.namprd15.prod.outlook.com (10.166.160.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Thu, 12 Apr 2018 11:41:15 +0000 Received: from DM3PR15MB0765.namprd15.prod.outlook.com ([fe80::31d8:2609:2ce1:fdf1]) by DM3PR15MB0765.namprd15.prod.outlook.com ([fe80::31d8:2609:2ce1:fdf1%13]) with mapi id 15.20.0675.012; Thu, 12 Apr 2018 11:41:15 +0000 From: Simon Perreault To: "tram@ietf.org" Thread-Topic: Scope of TURN-bis Thread-Index: AQHT0lMpa89S4wshgEudh2t3/pU0yw== Date: Thu, 12 Apr 2018 11:41:15 +0000 Message-ID: <3ECE3CCC-FC5F-4EB1-9CFB-7584B2580F0A@logmein.com> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.70.114.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM3PR15MB1036; 7:oJG6OyiHkFRetGFmuh1+RYgwxOr1U8TNLKTGGGV2nBNqnln+VzWYtLsJClt6GuNM84ErHQcFxUz+WVrGeYE6Y11Pj9ndcBRRj4w/KIvjeyR/+4/si1T9gpTUo38lLDsTOydr2fdV4kcg+zJW5KZfaeNN01U4e0ZD9dP4TeRadtFJ31vU+XEo20JkhODH09P5L4bbP/2E3HNkO6sTq7ylZllukLTuYNga4dwwyNI9fgIv0+jNbUctEzT8UaBI0h3E x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM3PR15MB1036; x-ms-traffictypediagnostic: DM3PR15MB1036: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM3PR15MB1036; BCL:0; PCL:0; RULEID:; SRVR:DM3PR15MB1036; x-forefront-prvs: 06400060E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(366004)(39860400002)(346002)(376002)(199004)(78642003)(189003)(59450400001)(81166006)(2900100001)(5250100002)(8676002)(486006)(6436002)(8936002)(6506007)(316002)(81156014)(106356001)(99286004)(1730700003)(3846002)(3660700001)(2906002)(68736007)(6486002)(3280700002)(102836004)(476003)(2501003)(6116002)(7736002)(14454004)(82746002)(26005)(36756003)(186003)(25786009)(478600001)(72206003)(86362001)(97736004)(5660300001)(6916009)(6306002)(33656002)(54896002)(2616005)(6512007)(83716003)(53936002)(66066001)(105586002)(5640700003)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM3PR15MB1036; H:DM3PR15MB0765.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: logmein.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: nME5iJ4dzsW89u/UEfp2NMD9yf/BCeUHzEoLcpOJeVp970Bhjb+9YOwWEf100k2W4xqSgOTU7vrE6d//2rHZ2r9Rnmh7coCOv4BtlDDBtWatUcQvAPVtwJ5DTV64IPsGzieo1ilWMrkzN+l3BXktT/3wbds/6+W6mfBo5dD7FJkuGd6b+6mmp5O0laxB4pzS spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3ECE3CCCFC5F4EB19CFB7584B2580F0Alogmeincom_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 7604e198-de12-40e8-66aa-08d5a06a4c72 X-OriginatorOrg: logmein.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7604e198-de12-40e8-66aa-08d5a06a4c72 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2018 11:41:15.1399 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84c4e5b0-26a0-4dac-b686-301d76713569 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR15MB1036 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-12_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [tram] Scope of TURN-bis 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, 12 Apr 2018 11:41:19 -0000 --_000_3ECE3CCCFC5F4EB19CFB7584B2580F0Alogmeincom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhcmVzdCB3b3JraW5nIGdyb3VwLA0KDQpUaGUgY2hhaXJzIGp1ZGdlIHRoYXQgY29uc2Vuc3Vz IGFyb3VuZCBleHBhbmRpbmcgdGhlIHNjb3BlIG9mIFRVUk4tYmlzIHRvIGluY2x1ZGUgYSBtZWNo YW5pc20gZm9yIG11bHRpcGxlIGFsbG9jYXRpb25zIGhhcyBub3QgbWF0ZXJpYWxpemVkIGluIHRo ZSB3b3JraW5nIGdyb3VwLiBJbiBhZGRpdGlvbiwgdGhlIGxldmVsIG9mIGVuZXJneSBpcyBnZW5l cmFsbHkgbG93LCBtYWtpbmcgc3VjaCBhIHNjb3BlIGV4cGFuc2lvbiB1bmxpa2VseSB0byBzdWNj ZWVkLiBUaGVyZWZvcmUsIHRoZSBjaGFpcnMgcmVxdWVzdCBvZiB0aGUgZWRpdG9ycyBhbmQgc2hl cGhlcmQgb2YgVFVSTi1iaXMgdG8gbWFpbnRhaW4gdGhlIGN1cnJlbnQgc2NvcGUgYW5kIHByb2Nl ZWQgd2l0aCB0aGUgcHVibGljYXRpb24gcHJvY2Vzcy4gSXQgaXMgYWxzbyBzdWdnZXN0ZWQgdG8g cGFydGllcyBpbnRlcmVzdGVkIGluIGEgbWVjaGFuaXNtIGZvciBtdWx0aXBsZSBhbGxvY2F0aW9u cyB0byB3cml0ZSBpdCB1cCwgaW4gSW50ZXJuZXQtRHJhZnQgZm9ybWF0LCBhcyBhbiBleHRlbnNp b24gdG8gdGhlIFRVUk4gcHJvdG9jb2wuDQoNClNpbW9uICYgR29uemFsbw0K --_000_3ECE3CCCFC5F4EB19CFB7584B2580F0Alogmeincom_ Content-Type: text/html; charset="utf-8" Content-ID: <1FEA599E4BA36E43B673658E7E9536EA@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJGUi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGVhcmVzdCB3b3JraW5nIGdyb3Vw LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5UaGUgY2hhaXJzIGp1ZGdlIHRoYXQgY29uc2Vuc3VzIGFyb3VuZCBleHBh bmRpbmcgdGhlIHNjb3BlIG9mIFRVUk4tYmlzIHRvIGluY2x1ZGUgYSBtZWNoYW5pc20gZm9yIG11 bHRpcGxlIGFsbG9jYXRpb25zIGhhcyBub3QgbWF0ZXJpYWxpemVkIGluIHRoZSB3b3JraW5nIGdy b3VwLiBJbiBhZGRpdGlvbiwgdGhlIGxldmVsIG9mIGVuZXJneQ0KIGlzIGdlbmVyYWxseSBsb3cs IG1ha2luZyBzdWNoIGEgc2NvcGUgZXhwYW5zaW9uIHVubGlrZWx5IHRvIHN1Y2NlZWQuIFRoZXJl Zm9yZSwgdGhlIGNoYWlycyByZXF1ZXN0IG9mIHRoZSBlZGl0b3JzIGFuZCBzaGVwaGVyZCBvZiBU VVJOLWJpcyB0byBtYWludGFpbiB0aGUgY3VycmVudCBzY29wZSBhbmQgcHJvY2VlZCB3aXRoIHRo ZSBwdWJsaWNhdGlvbiBwcm9jZXNzLiBJdCBpcyBhbHNvIHN1Z2dlc3RlZCB0byBwYXJ0aWVzIGlu dGVyZXN0ZWQgaW4NCiBhIG1lY2hhbmlzbSBmb3IgbXVsdGlwbGUgYWxsb2NhdGlvbnMgdG8gd3Jp dGUgaXQgdXAsIGluIEludGVybmV0LURyYWZ0IGZvcm1hdCwgYXMgYW4gZXh0ZW5zaW9uIHRvIHRo ZSBUVVJOIHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TaW1vbiAmYW1wOyBHb256YWxvPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3ECE3CCCFC5F4EB19CFB7584B2580F0Alogmeincom_-- From nobody Sat Apr 14 04:48:12 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 D3ACF124319 for ; Sat, 14 Apr 2018 04:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] 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 DMm48bQCwtOx for ; Sat, 14 Apr 2018 04:48:06 -0700 (PDT) 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 502471200C5 for ; Sat, 14 Apr 2018 04:48:06 -0700 (PDT) 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=ce31WMY+fzi9i05wDaw4rlKCSSm5YNhGTL1ZZ7xD8IE=; b=jwimJDy44/iWS5hAewWkqM+dGg8k+hldUPememne5WDt3PrRXnNDNG4TwCmqw4a61rLeLtnMmoAOJVId3OsmsXDT8QMClVfCCamYvOvV4P+eBJJEiyarT/Wk8e/DlkRtMNmR+8IVuEGqA4PPc0agHGzSKMJAavrnauY+A+7UNoU= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0088.outbound.protection.outlook.com [207.46.163.88]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-79-NDAnj4XOP6uyDbY1Saiw2Q-1; Sat, 14 Apr 2018 07:48:03 -0400 Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB2533.namprd03.prod.outlook.com (10.168.165.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Sat, 14 Apr 2018 11:48:02 +0000 Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::d8f0:24ac:4222:be23]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::d8f0:24ac:4222:be23%13]) with mapi id 15.20.0675.009; Sat, 14 Apr 2018 11:48:01 +0000 From: "Asveren, Tolga" To: "tram@ietf.org" Thread-Topic: Proto-Writeup for draft-ietf-tram-stun-pmtud-07 Thread-Index: AdPT1jAAHrlDyO6aRBeFDyoaklPJ2w== Date: Sat, 14 Apr 2018 11:48:01 +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; CY4PR03MB2533; 7:zXPUJpSAmsnAs73kw+4AaYsnRDWwrFulXjVhgYTCQ+ha6PnxSNeo45VdoAIIud5ibjeyb704tfsbNx/nOGsEsx1qEYq3X7Q/MaerLuQAvY8hE4B31f7Ry6Lk98zzZv8WB9QMKMLTjhvijmHLhNW9regLdVgyTy7whehf+Arwv7ZG/WnQJt/gwUdEK5XRmvVBprfbH+btJOkXLjIZz7dsayprzqLap8aq+bg7t6BnwBAYuIMUYNNSZmIhosz7HMuK; 20:BN6Ex8PoITuJMCZYjmoIBav8HEWWJZIiFeP52yjK4djzXaA0EWFh5Yqc3ec4EnwcSTZS4zegOsNhKCcQYNyP0RYtw/WhaGOzYy2DJFJ2vEfFk/rOPQmVvAqAQmNxm+X2GpTd5jkIFPSn1QmpbN6vLQV9dMmh2I0TSaCgsXptq7I= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR03MB2533; x-ms-traffictypediagnostic: CY4PR03MB2533: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR03MB2533; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2533; x-forefront-prvs: 0642A5E7BA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(376002)(39380400002)(346002)(396003)(366004)(189003)(199004)(2900100001)(478600001)(966005)(2906002)(6916009)(5630700001)(6506007)(102836004)(86362001)(99286004)(26005)(25786009)(59450400001)(7696005)(486006)(476003)(316002)(105586002)(8936002)(74316002)(33656002)(81156014)(81166006)(7736002)(106356001)(606006)(3846002)(6116002)(790700001)(3660700001)(6436002)(1730700003)(3280700002)(5660300001)(14454004)(186003)(68736007)(66066001)(2351001)(8676002)(53936002)(6306002)(97736004)(2501003)(236005)(5250100002)(9686003)(55016002)(54896002)(5640700003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB2533; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-microsoft-antispam-message-info: X9TQZ3K0RNRDKUtiiKdQwja4HeZ4JKdchy/7YHs0jfPHzUWdshBDXYRTMq84k2vwVFa1Urc+7PeNE7xwyJaR9nE6Oax7644k0MGlOgn7zYlN9SGqOgCWLgrPcWn10NpfPGsXx2A+vQfnShPwMmdM3qrqU8QT8ASkGMcSi02Q0qlIWxANhMfPDBignTAtqn2a spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: e5b2494f-6a85-4136-bad2-08d5a1fd93b6 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5b2494f-6a85-4136-bad2-08d5a1fd93b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2018 11:48:01.8567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2533 X-MC-Unique: NDAnj4XOP6uyDbY1Saiw2Q-1 Content-Type: multipart/alternative; boundary="_000_CY4PR03MB3160FAF54DA0434DE4C3D736A5B20CY4PR03MB3160namp_" Archived-At: Subject: [tram] Proto-Writeup for draft-ietf-tram-stun-pmtud-07 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: Sat, 14 Apr 2018 11:48:11 -0000 --_000_CY4PR03MB3160FAF54DA0434DE4C3D736A5B20CY4PR03MB3160namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable PROTO write up for draft-ietf-tram-stun-pmtud-07 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard, as indicated on the front page of the draft. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a Session Traversal Utilities for NAT (STUN) Usage = for Path MTU Discovery (PMTUD) between a client and a server. Working Group Summary: The working group had a strong consensus around this draft. Document Quality: The document quality is satisfactory. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Tolga Asveren is the document shepherd. Spencer Dawkins and Mirja Kuhlewind are the responsible Area director (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed version 06 of the draft, provided comm= ents. They have been discussed and satisfactorily addressed by version 07 o= f the draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. There have been sufficient discussions in the past about this draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The draft has sections pertaining to security and those are sufficiently = reviewed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. All draft authors also acknowledged that they are not aware of any IP= R associated with this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no remaining issues with nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional reviews are needed. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA Considerations section lists the new STUN Methods and new STUN att= ributes defined by this draft. They need to be added to IANA "STUN Paramete= rs Registry". (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. --_000_CY4PR03MB3160FAF54DA0434DE4C3D736A5B20CY4PR03MB3160namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

PROTO write up for  draft-ietf-tram-stun-pmtud-= 07

 

(1) What type of RFC is being requested (BCP, Propos= ed Standard,

Internet Standard, Informational, Experimental, or H= istoric)? Why is

this the proper type of RFC? Is this type of RFC ind= icated in the

title page header?

 

Proposed Standard, as indicated on the front page of= the draft.

 

(2) The IESG approval announcement includes a Docume= nt Announcement

Write-Up. Please provide such a Document Announcemen= t Write-Up. Recent

examples can be found in the "Action" anno= uncements for approved

documents. The approval announcement contains the fo= llowing sections:

 

Technical Summary:

 

This document describes a Session Traversal Utilitie= s for NAT (STUN) Usage for Path MTU Discovery (PMTUD) between a client and = a server.

 

Working Group Summary:

 

  The working group had a strong consensus arou= nd this draft.

 

Document Quality:

 

  The document quality is satisfactory.

 

 

Personnel:

 

Who is the Document Shepherd? Who is the Responsible= Area Director?

 

  Tolga Asveren is the document shepherd.<= /o:p>

  Spencer Dawkins and Mirja Kuhlewind are the r= esponsible Area director

 

(3) Briefly describe the review of this document tha= t was performed by

the Document Shepherd. If this version of the docume= nt is not ready

for publication, please explain why the document is = being forwarded to

the IESG.

 

  The document shepherd has reviewed version 06= of the draft, provided comments. They have been discussed and satisfactori= ly addressed by version 07 of the draft.

 

(4) Does the document Shepherd have any concerns abo= ut the depth or

breadth of the reviews that have been performed?

 

  No. There have been sufficient discussions in= the past about this draft.

 

(5) Do portions of the document need review from a p= articular or from

broader perspective, e.g., security, operational com= plexity, AAA, DNS,

DHCP, XML, or internationalization? If so, describe = the review that

took place.

 

  The draft has sections pertaining to security= and those are sufficiently reviewed.

 

(6) Describe any specific concerns or issues that th= e Document

Shepherd has with this document that the Responsible= Area Director

and/or the IESG should be aware of? For example, per= haps he or she is

uncomfortable with certain parts of the document, or= has concerns

whether there really is a need for it. In any event,= if the WG has

discussed those issues and has indicated that it sti= ll wishes to

advance the document, detail those concerns here.

 

  No concerns.

 

(7) Has each author confirmed that any and all appro= priate IPR

disclosures required for full conformance with the p= rovisions of BCP

78 and BCP 79 have already been filed. If not, expla= in why?

 

  Yes.

 

(8) Has an IPR disclosure been filed that references= this document? If

so, summarize any WG discussion and conclusion regar= ding the IPR

disclosures.

 

  No. All draft authors also acknowledged that = they are not aware of any IPR associated with this draft.

 

(9) How solid is the WG consensus behind this docume= nt? Does it

represent the strong concurrence of a few individual= s, with others

being silent, or does the WG as a whole understand a= nd agree with it?

 

  Strong consensus.

 

(10) Has anyone threatened an appeal or otherwise in= dicated extreme

discontent? If so, please summarise the areas of con= flict in separate

email messages to the Responsible Area Director. (It= should be in a

separate email because this questionnaire is publicl= y available.)

 

  No.

 

(11) Identify any ID nits the Document Shepherd has = found in this

document. (See http://www.ietf.org/tools/idnits/ and the

Internet-Drafts Checklist). Boilerplate checks are n= ot enough; this

check needs to be thorough.

 

  There are no remaining issues with nits.=

 

(12) Describe how the document meets any required fo= rmal review

criteria, such as the MIB Doctor, media type, and UR= I type reviews.

 

  No additional reviews are needed.<= /p>

 

(13) Have all references within this document been i= dentified as

either normative or informative?

 

  Yes.

 

(14) Are there normative references to documents tha= t are not ready

for advancement or are otherwise in an unclear state= ? If such

normative references exist, what is the plan for the= ir completion?

 

  No.

 

(15) Are there downward normative references referen= ces (see RFC

3967)? If so, list these downward references to supp= ort the Area

Director in the Last Call procedure.

 

  No.

 

 

 

(16) Will publication of this document change the st= atus of any

existing RFCs? Are those RFCs listed on the title pa= ge header, listed

in the abstract, and discussed in the introduction? = If the RFCs are

not listed in the Abstract and Introduction, explain= why, and point to

the part of the document where the relationship of t= his document to

the other RFCs is discussed. If this information is = not in the

document, explain why the WG considers it unnecessar= y.

 

No.

 

(17) Describe the Document Shepherd's review of the = IANA

considerations section, especially with regard to it= s consistency with

the body of the document. Confirm that all protocol = extensions that

the document makes are associated with the appropria= te reservations in

IANA registries. Confirm that any referenced IANA re= gistries have been

clearly identified. Confirm that newly created IANA = registries include

a detailed specification of the initial contents for= the registry,

that allocations procedures for future registrations= are defined, and

a reasonable name for the new registry has been sugg= ested (see RFC

5226).

 

The IANA Considerations section lists the new STUN M= ethods and new STUN attributes defined by this draft. They need to be added= to IANA "STUN Parameters Registry".

 

(18) List any new IANA registries that require Exper= t Review for

future allocations. Provide any public guidance that= the IESG would

find useful in selecting the IANA Experts for these = new registries.

 

None.

 

(19) Describe reviews and automated checks performed= by the Document

Shepherd to validate sections of the document writte= n in a formal

language, such as XML code, BNF rules, MIB definitio= ns, etc.

 

Not applicable.

 

--_000_CY4PR03MB3160FAF54DA0434DE4C3D736A5B20CY4PR03MB3160namp_-- From nobody Mon Apr 16 12:31:01 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 07C82120725; Mon, 16 Apr 2018 12:29:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152390695800.19624.250040937113641569.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2018 12:29:18 -0700 Archived-At: Subject: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram-?= =?utf-8?q?stunbis-16=3A_=28with_COMMENT=29?= 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, 16 Apr 2018 19:29:18 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tram-stunbis-16: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Maybe it would make sense to refer informationally to draft-ietf-tram-stun-pmtud in section 6.1? 2) sec 6.2.2: This sentence seems to assume that only one request is sent per TCP connection/each request sends out after a new SYN: "However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the SYN to establish the connection, it considers the transaction to have timed out.“ i don’t think that assumption would be correct. Maybe rephrase this sentence…? 3) Also section 6.2.2: Should the client send keep-alives if a connection is hold open but currently not used? If not, I guess further recommendation is needed to address the case where a transmission fails because an existing idle TCP connection was used that doesn’t work anymore. In this case, I'd say the recommendation would be to send a RST and try to open a new TCP connection. 4) Should section 9.2 maybe provide further guidance on the lifetime of the (server-selected) nonce? 5) I'm sure, I just missed something but how does a server know if a first request intends to use the Long-Term Credential Mechanism or not (see 9.2.3.1. and 9.2.4 I guess). Or is this pre-configured? 6) Section 6.3 says that this doc only specifies the procedures for the new spec in this document and subsequently says: "It checks [...] that the magic cookie field has the correct value..." However, given this spec obsoletes RFC5389, I think that section 11 should provide more guidance on how to handle "old" STUN messages. Or is the intention that an upgraded STUN server does not handle old requests anymore? If so that should be spelled out as well. 7) sec 14.5: "The value of the MESSAGE-INTEGRITY attribute is set to a dummy value." Should the dummy value be further specified? Also it looks like there was a compile problem on page 39. Is there text missing? 8) sec 17.6: Isn't "stuns 5349/upd" used for DTLS? If so, it should be registered! From nobody Mon Apr 16 12:57:19 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 3776C126FB3; Mon, 16 Apr 2018 12:57:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2018 12:57:12 -0700 Archived-At: Subject: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) 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, 16 Apr 2018 19:57:12 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-tram-stunbis-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5132 Can you please indicate how you addressed the points Matt Miller raised in his secdir review about the use of MD5. DETAIL > by the agent sending the indication. It primarily serves to > correlate requests with responses, though it also plays a small role > in helping to prevent certain types of attacks. The server also uses > the transaction ID as a key to identify each transaction uniquely > across all clients. As such, the transaction ID MUST be uniformly > and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be I didn't realize this was a SHOULD. ICE depends on it as a security condition, so it probably needs to be a MUST. > For a request or indication message, the agent MUST include the > USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes > in the message unless the agent knows from an external indication > which message integrity algorithm is supported by both agents. In > this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST > be included in addition to USERNAME. The HMAC for the MESSAGE- This text appears to conflict with S 7.3 of 5245-bis, which says: > STUN Security Feature it is understood that the corresponding STUN > Security Feature bit in the "nonce cookie" is set to 1. > > For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS > security feature, it is implied that the "Password algorithms" bit, > as defined in Section 17.1, is set to 1 in the "nonce cookie". I'm not sure I understand the bid down attack here or the proposed defense. Can you please walk through what the assumed attacker capabilities are, what the client and server capabilities are, how the bid down attack works, and how this protects against it? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > > In keeping with its tool nature, this specification defines an > extensible packet format, defines operation over several transport > protocols, and provides for two forms of authentication. > > STUN is intended to be used in context of one or more NAT traversal Nit: "in the context" > of [RFC0791]. Unless otherwise noted, numeric constants are in > decimal (base 10). > > All STUN messages comprise a 20-byte header followed by zero or more > Attributes. The STUN header contains a STUN message type, magic > cookie, transaction ID, and message length. You might want to list these in order. > The STUN usage must specify which transport protocol is used, and how > the agent determines the IP address and port of the recipient. > Section 8 describes a DNS-based method of determining the IP address > and port of a server that a usage may elect to use. STUN may be used > with anycast addresses, but only with UDP and in usages where > authentication is not used. Why this restriction? You should be able to use anycast with long-term AUTH for (say) TURN. > First, the initial value for RTO SHOULD be greater than 500 ms. The > exception cases for this "SHOULD" are when other mechanisms are used > to derive congestion thresholds (such as the ones defined in ICE for > fixed rate streams), or when STUN is used in non-Internet > environments with known network capacities. In fixed-line access > links, a value of 500 ms is RECOMMENDED. Second, the value of RTO I note that above you say "greater than 500 ms" but here you say "500 ms". Perhaps you mean greater than equal. > transaction over UDP or DTLS-over-UDP is also considered failed if > there has been a hard ICMP error [RFC1122]. For example, assuming an > RTO of 500ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, > 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not > received a response after 39500 ms, the client will consider the > transaction to have timed out. I note that these recommendations now seem crazily long. I assume the WG had consensus on this, but I wanted to note it. > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites MUST be > implemented and other cipher suites MAY be implemented. Perfect > Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS > cipher suites. Cipher suites with known weaknesses, such as those > based on (single) DES and RC4, MUST NOT be used. Implementations > MUST disable TLS-level compression. Would it be better to just cite to RFC 7525 here? > > o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the > value for the message integrity as described in Section 14.6, > using the password associated with the username. If the MESSAGE- > INTEGRITY-SHA256 attribute is not present, and using the same > password, compute the value for the message integrity as described This text is a bit unclear. I think you mean "If the MESSAGE- INTEGRITY-SHA256 attribute is not present, then use the same password to compute the..." > a nonce. The nonce provides the replay protection. It is a cookie, > selected by the server, and encoded in such a way as to indicate a > duration of validity or client identity from which it is valid. The > client retries the request, this time including its username and the > realm, and echoing the nonce provided by the server. The client also > includes a message-integrity, which provides an HMAC over the entire Nit: "a message integrity attribute". Also, how do I know which one to use? > ALTERNATE-SERVER where authentication of the response is not possible > or practical. If the transaction uses TLS or DTLS and if the > transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute > and if the server wants to redirect to a server that uses a different > certificate, then it MUST include an ALTERNATE-DOMAIN attribute > containing the subjectAltName of that certificate. 1. Why is MESSAGE-INTEGRITY-SHA256 relevant here? > o What authentication and message-integrity mechanisms are used. > > o The considerations around manual vs. automatic key derivation for > the integrity mechanism, as discussed in [RFC4107]. > > o What mechanisms are used to distinguish STUN messages from other Why is this required? It seems like that's a generic STUN feature. > to the end of the MESSAGE-INTEGRITY-SHA256 attribute prior to > calculating the HMAC over the STUN message, up to and including the > attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. Such > adjustment is necessary when attributes, such as FINGERPRINT, appear > after MESSAGE-INTEGRITY-SHA256. See also Appendix B.1 for examples > of such calculations. So if M-I-SHA256 and M-I appear together, one includes the other but not vice versa? > transport protocol uses TLS or DTLS. > > The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-8 > [RFC3629] encoded sequence of less than 128 characters (which can be > as long as 509 bytes when encoding them and as long as 763 bytes when > decoding them). Is it an A-label or a U-label? > that is not readily subject to offline dictionary attacks. > Protection of the channel itself, using TLS or DTLS, mitigates these > attacks. > > STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, > which is subject to bid down attacks by an on-path attacker. By an on-path attacker who can forge HMAC-SHA1 in real-time? That's a pretty serious adversary, so you should clarify here From nobody Mon Apr 16 14:49:30 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 E1014124234; Mon, 16 Apr 2018 14:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] 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 hss1EdT9QGyL; Mon, 16 Apr 2018 14:49:21 -0700 (PDT) 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 D92FD1270AB; Mon, 16 Apr 2018 14:49:20 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56] (unknown [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56]) (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 C1501AE844; Mon, 16 Apr 2018 23:49:17 +0200 (CEST) From: Marc Petit-Huguenin To: Dale Worley , gen-art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152237792217.20556.13689609450529144296@ietfa.amsl.com> Message-ID: Date: Mon, 16 Apr 2018 14:49:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152237792217.20556.13689609450529144296@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IgupQUc3qzDqiLRnNUGBRflEZxKDfK4cS" Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 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, 16 Apr 2018 21:49:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IgupQUc3qzDqiLRnNUGBRflEZxKDfK4cS Content-Type: multipart/mixed; boundary="gVIJ1773OUtCsOQbyp7RExn8vihTcoXsK"; protected-headers="v1" From: Marc Petit-Huguenin To: Dale Worley , gen-art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 References: <152237792217.20556.13689609450529144296@ietfa.amsl.com> In-Reply-To: <152237792217.20556.13689609450529144296@ietfa.amsl.com> --gVIJ1773OUtCsOQbyp7RExn8vihTcoXsK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thanks again for the review. Comments inline. On 03/30/2018 04:45 AM, Dale Worley wrote: > Reviewer: Dale Worley > Review result: Ready with Nits >=20 > 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 wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-tram-stunbis-16 > Reviewer: Dale R. Worley > Review Date: 2018-03-29 > IETF LC End Date: 2018-02-20 > IESG Telechat date: 2018-04-19 >=20 > Summary: >=20 > This draft is basically ready for publication, but has nits > that should be fixed before publication. >=20 > The only interesting item concerns section 17.1, where the assignment > of meanings to bits in the "security feature set" value is different > from the assignment in -16. This is either non-upward-compatible with > -16, or there is an error in either -16 or -17. >=20 > ---------------------------------------------------------------------- >=20 > 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. I still do not have text about that but, as this is blocking this respons= e since 2 weeks now, I am releasing it as is and will come back to that a= fter I process the other reviews that accumulated during my time travelin= g around Europe. >=20 > 3. Terminology >=20 > This section needs to be updated to reference RFC 8174, including > updating the paragraph (especially the final two lines) to read as > specified in RFC 8174: >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > "MAY", and "OPTIONAL" in this document are to be interpreted as > described in BCP 14 [RFC2119] [RFC8174] when, and only when, they= > appear in all capitals, as shown here. Updated. >=20 > 6.2.2. Sending over TCP or TLS-over-TCP >=20 > o if multiplexing other application protocols over that port, has > finished using that other protocol, and >=20 > The two clauses don't match in grammatical number. This should be > either >=20 > o if multiplexing other application protocols over that port, has > finished using those other protocols, and >=20 > or >=20 > o if multiplexing another application protocol over that port, has > finished using that other protocol, and Updated using the former. >=20 > 9.2.4. Receiving a Request >=20 > * 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). >=20 > There are two places where s/PASSWORD- ALGORITHM/PASSWORD-ALGORITHM/. Already fixed following a previous review. >=20 > 14.3. USERNAME >=20 > The value of USERNAME is a variable-length value containing the > authentication username. It MUST contain a UTF-8 [RFC3629] encoded > sequence of less than 509 bytes, and MUST have been processed using > the OpaqueString profile [RFC8265]. A compliant implementation MUST= > be able to parse UTF-8 encoded sequence of less than 763. >=20 > The final "763" is grammatically incorrect. I think you intend > s/763/763 bytes/, to parallel other items. Fixed. >=20 > 14.4. USERHASH >=20 > userhash =3D SHA-256(Opaque(username) ":" Opaque(realm)) >=20 > I believe that this should be >=20 > userhash =3D SHA-256(OpaqueString(username) ":" OpaqueString(realm))= Fixed. >=20 > 14.5. MESSAGE-INTEGRITY >=20 > Petit-Huguenin, et al. Expires September 6, 2018 [Page 40] >=20 > Internet-Draft Session Traversal Utilities for NAT (STUN) March 2018= >=20 > This bit of text appears as body text in the middle of page 40. Already fixed following a previous review. >=20 > 14.6. MESSAGE-INTEGRITY-SHA256 >=20 > The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA256 > [RFC2104] of the STUN message. 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 HMAC MUST NOT= > be truncated below a minimum size of 16 bytes. The value must be th= e > full 32 bytes unless the STUN Usage explicitly specifies that > truncation is allowed. STUN Usages may specify a minimum length > longer than 4 bytes. >=20 > This seems to be less clear than it could be. (And my apologies, some > of the redundancy was my suggestion!) Perhaps this is an improvement: >=20 > The value will be at most 32 bytes, MUST be at least 16 bytes, and > MUST be a multiple of 4 bytes. The value must be the full 32 bytes > unless the STUN Usage explicitly specifies that truncation is > allowed. STUN Usages may specify a minimum length longer than 16 > bytes. Applied. >=20 > 17.1. STUN Security Features Registry >=20 > A STUN Security Feature set defines 24 bit as flags. >=20 > IANA is requested to create a new registry containing the STUN > Security Features that are protected by the bid down attack > prevention mechanism described in section Section 9.2.1. >=20 > The initial STUN Security Features are: >=20 > Bit 0: Password algorithms > Bit 1: Username anonymity > Bit 2-23: Unassigned >=20 > Beware that the assignment of features to bits in the security feature > value has changed! Bit numbers are assigned from the left/high-order > end -- see figure 2 in the draft. So the *values* for these bits are: >=20 > 0x400000 Bit 0: Password algorithms > 0x200000 Bit 1: Username anonymity >=20 > But the values assigned in -15 were: >=20 > 0x000001: Password algorithms > 0x000002: Username anonymity Hmm, that was not the intent, and not how I read the text. Even in Figure= 2 less significant bits are on the right. So the intent is real tat bit= 0=3D0x001, bit1 =3D 0x002, and so on. All we do is about interoperability, so I added some t= ext that makes that less ambiguous. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --gVIJ1773OUtCsOQbyp7RExn8vihTcoXsK-- --IgupQUc3qzDqiLRnNUGBRflEZxKDfK4cS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrVGlsACgkQKcRFldZq fsS1bBAAnudmxrZShJan4mkDdoV+y0CNzgxTsWrnu3n4NEeaeOmISgVkxjXj8yGH Mi941v13fJz0J53XIWbfGrXKELUSibX5T8d40bc8fk7HCx6BK55Sopp5Iv7BNlAn xt1vOdE5vCUHcJY4Pg4LM9m8iMwSHy9KE0v4Y2ToI+Fsek+R02JzML2RtYJJg+nW cPVBpqESZQKcAOHpn9ilcNTs9t7pNJEZIo+PFYmPaWx5gYJdn7V+pj/uWsTc4Xbs qOlFvGeIwhXjHHk19HkuxCnijizCzKvPLShIAfZGSXbVncaS85LMF1sGi1QRDosm sduBclVUwPruLtyp+HyF1LSuZpdNdSj+JlhyyHE7AzoAJ/t/BK0xYr+Y3joD5fHM TutGRZuuMjxiQTc8pb9agkBlEwfsyjd3lhJhxcycIRBYqgyugD9vHYEvV8K7zKHq yPr+KG4q6v80TyZ7HZfAh5kybT3IeDQUT8qwVxZJE87gbfgoN6sF8r878pdkl1wG NEytoAHbCMi94tUDdjRe3heT1cMmRzYb8lvfx8t5b4zpMjDB8d/sIPNQhMlqvPkY 4O/iFrYf3XIKH/MCfxvuQEGE8KoJzNWFgu5sqwKq7lAZEaU/UIlJg22YQmePQ7L3 Z9ii7rhducYCnv0CBri9G8qPf3YdRi932SOdW4Krpgvux+HHcTc= =K23D -----END PGP SIGNATURE----- --IgupQUc3qzDqiLRnNUGBRflEZxKDfK4cS-- From nobody Mon Apr 16 16:43: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 0A82E12D77B; Mon, 16 Apr 2018 16:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] 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 g7WVbaKAuQe4; Mon, 16 Apr 2018 16:43:36 -0700 (PDT) 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 7778C12D72F; Mon, 16 Apr 2018 16:43:36 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56] (unknown [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56]) (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 03A18AE844; Tue, 17 Apr 2018 01:43:32 +0200 (CEST) To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: Date: Mon, 16 Apr 2018 16:43:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152270998513.17947.16209089088681034529@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wrT326OxbEtRBMlcX6rsyVx2RhvLD8BXB" Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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, 16 Apr 2018 23:43:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wrT326OxbEtRBMlcX6rsyVx2RhvLD8BXB Content-Type: multipart/mixed; boundary="Jt9A28QuWskETTzYamIOMBVhRqz92RFHA"; protected-headers="v1" From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: <152270998513.17947.16209089088681034529@ietfa.amsl.com> --Jt9A28QuWskETTzYamIOMBVhRqz92RFHA Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Peter, Thanks for the review and sorry for the delay in responding, I was travel= ing for the last 4 weeks. See my responses inline. On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: > Reviewer: Peter Saint-Andre > Review result: Ready with Nits >=20 > Section 1 states: >=20 > Implementations and deployments of a STUN usage using TLS or DTLS > should follow the recommendations in [RFC7525]. >=20 > Wouldn't the security considerations be a better location for that text= ? Moved there. >=20 > And given that this specification cites RFC 8174, I suggest changing > "should" to "SHOULD". Done. >=20 > (I suggest that the authors review the usage of lowercase and uppercase= > requirements keywords, because there might be inconsistencies, e.g., in= > the first paragraphs of Section 6.1 and Section 6.2.) These sections are identical to RFC 5389 and so I am reluctant to modify = them as they already went through an IESG review. I reviewed the lowerca= se keywords in these two sections and did not find any specific case that= would create an interoperability issue, but please let me know if you th= ink otherwise. >=20 > In Section 4, please consider spelling out "SIP" on first use and > including a reference to RFC 3261. Done. >=20 > The first paragaraph of Section 6.2.3 restates recommendations from RFC= > 7525; why not simply reference that specification? The original text in RFC5389 said this: " When STUN is run by itself over TLS-over-TCP, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a minimum. [...]" The new text is an attempt at updating it in the same spirit of giving mi= nimal instructions and complementing them with a reference to RFC 7525 - = which was the reason for the reference to RFC 7525 there. So I kept the text there, followed by the following paragraph, in additio= n of moving the original last paragraph in the Security Consideration sec= tion: " These recommendations are just a part of the the recommendations in [RFC7525] that implementations and deployments of a STUN usage using TLS or DTLS SHOULD follow." >=20 > Section 6.3.4 states: >=20 > o If the error code is 500 through 599, the client MAY resend the > request; clients that do so MUST limit the number of times they d= o > this. >=20 > It is reasonable to provide guidance as to the number of re-sends? Same issue here, that's a section that is unmodified from RFC 5389. As l= ong as the client does not enter an endless loop of retransmission, choos= ing different numbers of re-sends does not affect interoperability. >=20 > Section 9.1.1 and other sections invoke the OpaqueString profile of the= > PRECIS FreeformClass; it might be helpful to mention that the profile i= s > used to handle Unicode characters outside the ASCII range, and that no > changes result if only ASCII characters are used. Hmm. But in that case the application has first to test that the string = is in the ASCII range. Isn't that better to always assume that the input= string will contain Unicode, and let the implementation of OpaqueString = short-circuit the processing in the case of an all-ASCII string? >=20 > In Section 14.2, please consider spelling out "ALG" on first use. Done. >=20 > A reference to RFC 6151 seems appropriate regarding the fact that this > specification retains the use of MD5; in particular, the usage here is > actually HMAC-MD5, which is still sanctioned by RFC 6151. >=20 Done. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --Jt9A28QuWskETTzYamIOMBVhRqz92RFHA-- --wrT326OxbEtRBMlcX6rsyVx2RhvLD8BXB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrVNR0ACgkQKcRFldZq fsSY2A/+JtNnslRVcf0zfAQbJvF9TXncq2p2Iv8inXLQQfv4rMj4FXI150HzxhYU ytUUN6s/I2gcjD+AERjXwyCjsU36W6SVwkfFVPwPzYh4J4Z1LLd6nJCGbmyf2J8W R2P+hkS7PI2zZNkLXzrK0nDFKfV6ZtXlWxVrd7HPyuYcgVw+V6nxrinlfNRbt3Oq qNdtpg1Qrp4M27Y/NWVVc3GUTFx3cGGwhlpBNvySyCtKk05uyEJuA22X7EZT9DFp OwcHUX/y7TFw/PFmBYSIUOaOhaH7PutwU+tsEaTQ/UssH/hDBe430N9KEmV/S3GK m6y0O8Mdr4yGHHoBFS8UOcpWmT1xA37fDE0MUiggvZwCtJI4C3IPjRZwhoYXGQxf mxBL+wP4tun+EWThqblmJYLm3AAmw8sfcj0TSj+A34FERweZUYu/6cKfNN9n71HB 0ofxfupxAJZakAGHld0mkmkinak8h79yK5rfWbj9T/5wnyyPhMlfa3WSkVj5BE+b bnPs28GX5dz/avDYVtjTkuE4QMIdNFU7cqhf//Kq302bKNTt9VdlLnqc+mXXq1e9 yC4Tx+nRDOGgv9YYXyXZ7f4XsBRGf26SJtM7jszsgOEQm8ccUjtfDzlGgAKd6qeZ Nu3e3LKJnFUApWptbgesoy1RxKFXge/QwAUFK6HisDAhFt92s7o= =1oCQ -----END PGP SIGNATURE----- --wrT326OxbEtRBMlcX6rsyVx2RhvLD8BXB-- From nobody Mon Apr 16 17:22:27 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 3DB8112D957 for ; Mon, 16 Apr 2018 17:22:23 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 lDScpP2RQ3gt for ; Mon, 16 Apr 2018 17:22:20 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 EE74112D88E for ; Mon, 16 Apr 2018 17:22:19 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id r69so13972364iod.8 for ; Mon, 16 Apr 2018 17:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=7+ws6D50gwwfnkvNh0mrKwGqev3OS2PSkvow0Cb3YLw=; b=IGGSzjJe5nor2jsbqbYfw0LxZClJdrUPwN4L109paW1y7aiIbhrsfdRcFgZTJr8Csh QoqBvncH0DKx6Xp/7fAfrwrMHegN2JZwq33j09++FBi5oKJFTk9UgXQIdJ/t+tIICN7s cyEUzt1GrCm+oFGMv266Hmv/x2YBSucVHkIxI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=7+ws6D50gwwfnkvNh0mrKwGqev3OS2PSkvow0Cb3YLw=; b=Aw+89+peyaQlvaoCB1+0G1YC1ZkOvr1a1mHdifK0AbJc813tD17WlLL/xEuRfTdYKr JXysLH/HDmxM+T8bX2BRrv76Mcwi3Q8K2XxfJKWe46GARtIu6tDB2r09suJ05K/q/bVh NwUv0STeBrS0/F8FHHlyVrQZ9JtpTWce/f1hxOSde6nS2zhfeT9JbzjAEMJP6X+/NcCP 0z9vFJIUNTyXoH2Tv3T6qyT/QHWdDvmEOHIo3sGxqykjQhXvzjGYidyIgpfUKL2JxCGK t2gs2DjUwHCz5D4YtvNdydL9wEHwSFHUo4+gC7HV9WdStGWJwuKZiUZWN43KGJBO9D5R KKtQ== X-Gm-Message-State: ALQs6tC7gV5+FB74WQUEjVN6sumKJ+ZuTb0Ci1phLnroI8BXhHNkKAhF 4BSP5x4Rq2iV9atvcgRttoz82Q== X-Google-Smtp-Source: AIpwx49FZRu0VJpi+P5nKrf1HtizWwZc7lmjyAMOOZ7FRLd1dVkwSugbqnTOgpnqHB3Q6j2ab7c3uw== X-Received: by 10.107.146.86 with SMTP id u83mr8089924iod.110.1523924539262; Mon, 16 Apr 2018 17:22:19 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id b195-v6sm5192192itb.22.2018.04.16.17.22.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 17:22:18 -0700 (PDT) To: Marc Petit-Huguenin , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Mon, 16 Apr 2018 18:22:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yKq6lTWRoEdhfUFxtNTJ5NFOtrykyqKwH" Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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, 17 Apr 2018 00:22:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yKq6lTWRoEdhfUFxtNTJ5NFOtrykyqKwH Content-Type: multipart/mixed; boundary="lTWqg8rOIoLIFHGBTFCy5EECPoAVg8RYS"; protected-headers="v1" From: Peter Saint-Andre To: Marc Petit-Huguenin , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --lTWqg8rOIoLIFHGBTFCy5EECPoAVg8RYS Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Marc, a few further comments inline. On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: > Hi Peter, >=20 > Thanks for the review and sorry for the delay in responding, I was trav= eling for the last 4 weeks. >=20 > See my responses inline. >=20 > On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >> Reviewer: Peter Saint-Andre >> Review result: Ready with Nits >> >> The first paragaraph of Section 6.2.3 restates recommendations from RF= C >> 7525; why not simply reference that specification? >=20 > The original text in RFC5389 said this: >=20 > " When STUN is run by itself over TLS-over-TCP, the > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a > minimum. [...]" >=20 > The new text is an attempt at updating it in the same spirit of giving = minimal instructions and complementing them with a reference to RFC 7525 = - which was the reason for the reference to RFC 7525 there. >=20 > So I kept the text there, followed by the following paragraph, in addit= ion of moving the original last paragraph in the Security Consideration s= ection: >=20 > " These recommendations are just a part of the the recommendations in > [RFC7525] that implementations and deployments of a STUN usage using > TLS or DTLS SHOULD follow." I would instead suggest that we do something like Section 2 of RFC 7590 for XMPP: The best current practices documented in the "Recommendations for Secure Use of TLS and DTLS" [RFC7525] are included here by reference. Instead of repeating those recommendations here, this document mostly provides supplementary information regarding secure implementation and deployment of XMPP technologies. Here's the rationale: RFC 7525 is likely to be updated/replaced more quickly than STUNbis. If STUNbis recommends a particular cipher suite that 7525bis stops recommending, in the absence of STUNter will STUN implementations keep following STUNbis or will they upgrade to whatever 7525bis recommends? I suggest it will be the former, which is not what we want. >> Section 6.3.4 states: >> >> o If the error code is 500 through 599, the client MAY resend the >> request; clients that do so MUST limit the number of times they = do >> this. >> >> It is reasonable to provide guidance as to the number of re-sends? >=20 > Same issue here, that's a section that is unmodified from RFC 5389.=20 I understand. Now is our chance to fix it. :-) > As long as the client does not enter an endless loop of retransmission= , choosing different numbers of re-sends does not affect interoperability= =2E Choosing different numbers is OK, but choosing an infinite number is not. Can we provide guidance as to how many is too many? 10? 50? 100? >> Section 9.1.1 and other sections invoke the OpaqueString profile of th= e >> PRECIS FreeformClass; it might be helpful to mention that the profile = is >> used to handle Unicode characters outside the ASCII range, and that no= >> changes result if only ASCII characters are used. >=20 > Hmm. But in that case the application has first to test that the strin= g is in the ASCII range. Isn't that better to always assume that the inp= ut string will contain Unicode, and let the implementation of OpaqueStrin= g short-circuit the processing in the case of an all-ASCII string? Yes, I meant that as an informational note to implementers so they would worry less. But it's not necessary and I think you can safely ignore it. Peter --lTWqg8rOIoLIFHGBTFCy5EECPoAVg8RYS-- --yKq6lTWRoEdhfUFxtNTJ5NFOtrykyqKwH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrVPjkACgkQZWGMGH9o FKkiHQ/9Gcqq43e6sydBGErjTzpzLWp/zL4W9PtWZ2Ay7RQsyw5GbI6coS/5ifbA hjm6bqNlvZRf4z8WfHnZhw+0iIjXTFBDh7HaAFM9UR1pMSK/RGQOVo21E7LyIhmJ mSiVY5CgUSBnRNxw6VLxa22lnouUh/mlUK175rUsn/+l57GfC+lyIm1Qimhgx+ch Krt6S4YzeWgxSEZ0im7HQSa446Ok0UXopbFzusDEDW8SjOgsTUnJtCmq35YNE1rN FXlmLSewxEns4jXJIRHLXknSD9WZqeA4SH3zdY79kE0BW2JUW7UxuJj5oA0soKYo FYsl8ZlO0jhaX7o5kNJ+tfpJ2haJr1UedKOYrRa1AJ8ZeRVs3HpH8Ybt3IYfQyzX WvyZkfpafvf9JWrGja1ymRs0/+VuF3MndYx6XAF6QgSctuvf6IxUCv7i2tYGIRi4 TXmkwyrAt5x9VIoqL53m3auV817bXFyeswE+5db8RwGX8d3GXpVKFaJG0btGNPBs /kK0fKyflF4LOUOhoFquJgm+EdRdZOYoxgFi+tePjji9D0xRJrMY18RLrtz/aPZg fJ6QB/dM3CLsfG56Hc6OCNR6+R5ZTrg0kPiy5lnqt0b/d0C7oONnQayQxNomRzhG hhKOFItuwVrzbxBRQTa8XlDECAgO6OrPTS+Ummev8Tyj6Si6l2I= =kVa5 -----END PGP SIGNATURE----- --yKq6lTWRoEdhfUFxtNTJ5NFOtrykyqKwH-- From nobody Mon Apr 16 19:11:09 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 399651270AC; Mon, 16 Apr 2018 19:11:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152393106321.26096.12146305230255636553.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2018 19:11:03 -0700 Archived-At: Subject: [tram] Ben Campbell's No Objection on draft-ietf-tram-stunbis-16: (with COMMENT) 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, 17 Apr 2018 02:11:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tram-stunbis-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, thanks for this work. For the record, I have mainly reviewed the diff. General: I think Peter's ART-ART review has some points worth addressing. §1, last paragraph: This seems out of place. Also, I wonder if it should be stated more strongly, perhaps with a SHOULD or even MUST. §3: RFC 8174 offers it's own recommended boilerplate; is there a reason not to use it? §6.2.1, third paragraph: " The value SHOULD be considered stale and discarded after 10 minutes without any transactions to the same server. " This is a bit ambiguous. I think it means the value is stale if no transactions have occurred in the last 10 minutes, But I think it could be read to say that there should be no transactions to the same server once one considers the value as stale. §9.1.4: Does it make sense to signal that "an attack took place" rather than signaling "integrity protection was violated" and let the human operators decide if that implies an attack? §14.3: "A compliant implementation MUST be able to parse UTF-8 encoded sequence of less than 763." 763 whats? §15.3, 2nd bullet: I'm not sure I understand what is meant by "get an updated external mechanism" From nobody Mon Apr 16 20:12: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 7106812E8A8 for ; Mon, 16 Apr 2018 20:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 ITW_UnSTJBpJ for ; Mon, 16 Apr 2018 20:12:47 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 39CFD12D87D for ; Mon, 16 Apr 2018 20:12:47 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id e123-v6so16601542oih.13 for ; Mon, 16 Apr 2018 20:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IFyy3t3f0w0rhVjJObNoYJJtzFuxyS23dHdKVg3cEtI=; b=Uabz2hEV1L95r9xO7bk+BDXYHH6c/nNQ9J5k4y2jp8s8Gsfv+/V4uOfGyh4vO/n/pm JN7FD81Dxil+kCz7xPAqUQavF71zatXeB3mSd6J7qvc5kiYJ6IQ+/vB48B8rzDWtu6j6 llFMpKLPJptwQXtYyLHk7yY+FlasVQ9ayu0MogCe7/pJ0OAI/eSxmn2xKiF8M+OSX/qc 8LMyYN7p9BGGSksRucFfBemarC+6qp1RMyGw8TLnQTW1XghwH75QUzfHKvU8tfMNcyLZ ZmK1Led0y7/lgeKtone/5nefxM9kJufc0WdOQkQ0XyK/u6SAXSlAhL5PJL9gF9ZotvUe ZkIA== 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=IFyy3t3f0w0rhVjJObNoYJJtzFuxyS23dHdKVg3cEtI=; b=i7ghLVMsxwixvvV7+JNei+3BPOyXHjZC/U+UIn5TDJsAUNvUat0tVm50Xm+TOmf3UD k3NYjC+9Ox9dUtN3zOdJPvu/14rRKisOmtkzQ+z01h4qhcyrFc/TcrA+uUvB99nftdoH 9yPHbxYBj+2VqTZ7Uv9qxLkRrUli9OxfLzd+C94CcoPz8mjPhYyi2+qeofQhgpQf9KJE LA1mRfisZfiy804YDZO2ClE/0xH6dpaZDtksQE5GQ/QS968yt7AnDM6ZT9dk+pWOuxSo IM6XINc/cHWcZ5HzgpPE4xNyEFZVWux9BrKimcOzFqNFFZDhbOfDUiW0WE1wUff8pAKp 17EQ== X-Gm-Message-State: ALQs6tDlHWiB9ijXkQulRnmPGGUXpYX1WAsAOZuGwh0AbXVcSG/wAPUv DLOfts9nM5Me636YB2b6lUszhdZNLsZu6O++UXagZg== X-Google-Smtp-Source: AIpwx48gZ1dREmC4TUjWmRKeij2o3UNmiqYKklONGKzy+ZhTa0gkVk8QR50gvCjulj3ZWq8RC9bOoODT6hhGCnEnLw4= X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr184561oib.138.1523934766633; Mon, 16 Apr 2018 20:12:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.132 with HTTP; Mon, 16 Apr 2018 20:12:06 -0700 (PDT) In-Reply-To: References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 16 Apr 2018 20:12:06 -0700 Message-ID: To: Peter Saint-Andre Cc: Marc Petit-Huguenin , art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org Content-Type: multipart/alternative; boundary="0000000000006d32cd056a02b694" Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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, 17 Apr 2018 03:12:50 -0000 --0000000000006d32cd056a02b694 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre wrote: > Hi Marc, a few further comments inline. > > On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: > > Hi Peter, > > > > Thanks for the review and sorry for the delay in responding, I was > traveling for the last 4 weeks. > > > > See my responses inline. > > > > On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: > >> Reviewer: Peter Saint-Andre > >> Review result: Ready with Nits > >> > > > > >> The first paragaraph of Section 6.2.3 restates recommendations from RFC > >> 7525; why not simply reference that specification? > > > > The original text in RFC5389 said this: > > > > " When STUN is run by itself over TLS-over-TCP, the > > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a > > minimum. [...]" > > > > The new text is an attempt at updating it in the same spirit of giving > minimal instructions and complementing them with a reference to RFC 7525 - > which was the reason for the reference to RFC 7525 there. > > > > So I kept the text there, followed by the following paragraph, in > addition of moving the original last paragraph in the Security > Consideration section: > > > > " These recommendations are just a part of the the recommendations in > > [RFC7525] that implementations and deployments of a STUN usage using > > TLS or DTLS SHOULD follow." > > I would instead suggest that we do something like Section 2 of RFC 7590 > for XMPP: > > The best current practices documented in the "Recommendations for > Secure Use of TLS and DTLS" [RFC7525] are included here by reference. > Instead of repeating those recommendations here, this document mostly > provides supplementary information regarding secure implementation > and deployment of XMPP technologies. > > Here's the rationale: RFC 7525 is likely to be updated/replaced more > quickly than STUNbis. If STUNbis recommends a particular cipher suite > that 7525bis stops recommending, in the absence of STUNter will STUN > implementations keep following STUNbis or will they upgrade to whatever > 7525bis recommends? I suggest it will be the former, which is not what > we want. > I forgot about this in my review, but you should also profile ciphers for TLS 1.3. -Ekr >> Section 6.3.4 states: > >> > >> o If the error code is 500 through 599, the client MAY resend the > >> request; clients that do so MUST limit the number of times they do > >> this. > >> > >> It is reasonable to provide guidance as to the number of re-sends? > > > > Same issue here, that's a section that is unmodified from RFC 5389. > > I understand. Now is our chance to fix it. :-) > > > As long as the client does not enter an endless loop of retransmission, > choosing different numbers of re-sends does not affect interoperability. > > Choosing different numbers is OK, but choosing an infinite number is > not. Can we provide guidance as to how many is too many? 10? 50? 100? > > >> Section 9.1.1 and other sections invoke the OpaqueString profile of the > >> PRECIS FreeformClass; it might be helpful to mention that the profile is > >> used to handle Unicode characters outside the ASCII range, and that no > >> changes result if only ASCII characters are used. > > > > Hmm. But in that case the application has first to test that the string > is in the ASCII range. Isn't that better to always assume that the input > string will contain Unicode, and let the implementation of OpaqueString > short-circuit the processing in the case of an all-ASCII string? > > Yes, I meant that as an informational note to implementers so they would > worry less. But it's not necessary and I think you can safely ignore it. > > Peter > > --0000000000006d32cd056a02b694 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre &l= t;stpeter@mozilla.= com> wrote:
Hi Marc, a few = further comments inline.

On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote:
> Hi Peter,
>
> Thanks for the review and sorry for the delay in responding, I was tra= veling for the last 4 weeks.
>
> See my responses inline.
>
> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote:
>> Reviewer: Peter Saint-Andre
>> Review result: Ready with Nits
>>

<snip/>

>> The first paragaraph of Section 6.2.3 restates recommendations fro= m RFC
>> 7525; why not simply reference that specification?
>
> The original text in RFC5389 said this:
>
> " When STUN is run by itself over TLS-over-TCP, the
>=C2=A0 =C2=A0TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implement= ed at a
>=C2=A0 =C2=A0minimum. [...]"
>
> The new text is an attempt at updating it in the same spirit of giving= minimal instructions and complementing them with a reference to RFC 7525 -= which was the reason for the reference to RFC 7525 there.
>
> So I kept the text there, followed by the following paragraph, in addi= tion of moving the original last paragraph in the Security Consideration se= ction:
>
> " These recommendations are just a part of the the recommendation= s in
>=C2=A0 =C2=A0[RFC7525] that implementations and deployments of a STUN u= sage using
>=C2=A0 =C2=A0TLS or DTLS SHOULD follow."

I would instead suggest that we do something like Section 2 of RFC 7= 590
for XMPP:

=C2=A0 =C2=A0The best current practices documented in the "Recommendat= ions for
=C2=A0 =C2=A0Secure Use of TLS and DTLS" [RFC7525] are included here b= y reference.
=C2=A0 =C2=A0Instead of repeating those recommendations here, this document= mostly
=C2=A0 =C2=A0provides supplementary information regarding secure implementa= tion
=C2=A0 =C2=A0and deployment of XMPP technologies.

Here's the rationale: RFC 7525 is likely to be updated/replaced more quickly than STUNbis. If STUNbis recommends a particular cipher suite
that 7525bis stops recommending, in the absence of STUNter will STUN
implementations keep following STUNbis or will they upgrade to whatever
7525bis recommends? I suggest it will be the former, which is not what
we want.

I forgot about thi= s in my review, but you should also profile ciphers for TLS 1.3.
=
-Ekr

>> Section 6.3.4 states:
>>
>>=C2=A0 =C2=A0 o=C2=A0 If the error code is 500 through 599, the cli= ent MAY resend the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0request; clients that do so MUST limit t= he number of times they do
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0this.
>>
>> It is reasonable to provide guidance as to the number of re-sends?=
>
> Same issue here, that's a section that is unmodified from RFC 5389= .

I understand. Now is our chance to fix it. :-)

>=C2=A0 As long as the client does not enter an endless loop of retransm= ission, choosing different numbers of re-sends does not affect interoperabi= lity.

Choosing different numbers is OK, but choosing an infinite number is=
not. Can we provide guidance as to how many is too many? 10? 50? 100?

>> Section 9.1.1 and other sections invoke the OpaqueString profile o= f the
>> PRECIS FreeformClass; it might be helpful to mention that the prof= ile is
>> used to handle Unicode characters outside the ASCII range, and tha= t no
>> changes result if only ASCII characters are used.
>
> Hmm.=C2=A0 But in that case the application has first to test that the= string is in the ASCII range.=C2=A0 Isn't that better to always assume= that the input string will contain Unicode, and let the implementation of = OpaqueString short-circuit the processing in the case of an all-ASCII strin= g?

Yes, I meant that as an informational note to implementers so they w= ould
worry less. But it's not necessary and I think you can safely ignore it= .

Peter


--0000000000006d32cd056a02b694-- From nobody Tue Apr 17 03:00:30 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 BC30112D779; Tue, 17 Apr 2018 03:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 2AFpUJ5Xl1HV; Tue, 17 Apr 2018 03:00:16 -0700 (PDT) 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 ECD0612762F; Tue, 17 Apr 2018 03:00:15 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56] (unknown [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56]) (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 9340CAE8D8; Tue, 17 Apr 2018 12:00:12 +0200 (CEST) To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Date: Tue, 17 Apr 2018 03:00:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kuGjWJaKegyCNzuRL9CzladtYkEpyPgNl" Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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, 17 Apr 2018 10:00:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kuGjWJaKegyCNzuRL9CzladtYkEpyPgNl Content-Type: multipart/mixed; boundary="fnF6DRKn4WOd5H0ugYlTGpALhvdtfMAjs"; protected-headers="v1" From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --fnF6DRKn4WOd5H0ugYlTGpALhvdtfMAjs Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/16/2018 05:22 PM, Peter Saint-Andre wrote: > Hi Marc, a few further comments inline. >=20 > On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >> Hi Peter, >> >> Thanks for the review and sorry for the delay in responding, I was tra= veling for the last 4 weeks. >> >> See my responses inline. >> >> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>> Reviewer: Peter Saint-Andre >>> Review result: Ready with Nits >>> >=20 > >=20 >>> The first paragaraph of Section 6.2.3 restates recommendations from R= FC >>> 7525; why not simply reference that specification? >> >> The original text in RFC5389 said this: >> >> " When STUN is run by itself over TLS-over-TCP, the >> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >> minimum. [...]" >> >> The new text is an attempt at updating it in the same spirit of giving= minimal instructions and complementing them with a reference to RFC 7525= - which was the reason for the reference to RFC 7525 there. >> >> So I kept the text there, followed by the following paragraph, in addi= tion of moving the original last paragraph in the Security Consideration = section: >> >> " These recommendations are just a part of the the recommendations in >> [RFC7525] that implementations and deployments of a STUN usage using= >> TLS or DTLS SHOULD follow." >=20 > I would instead suggest that we do something like Section 2 of RFC 7590= > for XMPP: >=20 > The best current practices documented in the "Recommendations for > Secure Use of TLS and DTLS" [RFC7525] are included here by reference= =2E > Instead of repeating those recommendations here, this document mostl= y > provides supplementary information regarding secure implementation > and deployment of XMPP technologies. >=20 > Here's the rationale: RFC 7525 is likely to be updated/replaced more > quickly than STUNbis. If STUNbis recommends a particular cipher suite > that 7525bis stops recommending, in the absence of STUNter will STUN > implementations keep following STUNbis or will they upgrade to whatever= > 7525bis recommends? I suggest it will be the former, which is not what > we want. All right, makes sense. I'll add something like this on my next round of= reviews, most likely this Friday. >=20 >>> Section 6.3.4 states: >>> >>> o If the error code is 500 through 599, the client MAY resend the= >>> request; clients that do so MUST limit the number of times they= do >>> this. >>> >>> It is reasonable to provide guidance as to the number of re-sends? >> >> Same issue here, that's a section that is unmodified from RFC 5389.=20 >=20 > I understand. Now is our chance to fix it. :-) >=20 >> As long as the client does not enter an endless loop of retransmissio= n, choosing different numbers of re-sends does not affect interoperabilit= y. >=20 > Choosing different numbers is OK, but choosing an infinite number is > not. Can we provide guidance as to how many is too many? 10? 50? 100? Well, the text already states that an infinite number of of re-sends is n= ot compliant. Anyway, I am not sure how to determine a reasonable number= , but I'll try. >=20 >>> Section 9.1.1 and other sections invoke the OpaqueString profile of t= he >>> PRECIS FreeformClass; it might be helpful to mention that the profile= is >>> used to handle Unicode characters outside the ASCII range, and that n= o >>> changes result if only ASCII characters are used. >> >> Hmm. But in that case the application has first to test that the stri= ng is in the ASCII range. Isn't that better to always assume that the in= put string will contain Unicode, and let the implementation of OpaqueStri= ng short-circuit the processing in the case of an all-ASCII string? >=20 > Yes, I meant that as an informational note to implementers so they woul= d > worry less. But it's not necessary and I think you can safely ignore it= =2E >=20 > Peter >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --fnF6DRKn4WOd5H0ugYlTGpALhvdtfMAjs-- --kuGjWJaKegyCNzuRL9CzladtYkEpyPgNl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrVxaoACgkQKcRFldZq fsRINw//SfqycpcdyLn9xQNNVz6DD6XHz7GmwfwRaevw90L42FzQfn0fIbilp+7o MhG+CW3vfUPdCQwGatDSp97xJ44TdQW/D54/31rLeD+4iYSlenect9P+QfZVIWV1 uypAgTwJJ38slb1Nz8DTMw2UQVQWyd7bdzMj0ICi1Q2Nae8zEI5ouF9DrUcMOTDG 5pFF4CBYxJ7Cu4gOy8yqBcR3dQUll0Y7SPZbF0+7De7s+1i4acA/v0/PxgSDBTQC Cm5LxQNdmvHrz613jgVo+YbGt69N6gFRpxaTfxhslq/BmuHuA+kBmgjlwd4vDLwH kHFomjucOCgof89m0ESKS66OGXhV2ZhiGcpQAQbS52iRbEUIUnKwzWWHyddARSiJ tAFFwK0+qAu2wE6uDGP3yneNuuAYDzSRRshyl4D2QPEJjkslhlJFMD4HSGYPQkaP E2SD/5zufn2U0XtmlaJoQKMYe14qUELwlCSW0IMZlOZYm92/mOIWShCWKJMeaFjJ rBYcNfgRTFOAdPacsN5cih+Dah1pLh9P0Mf/++Khcpn6UO9+tjDqTvaj0rHCxI/N IbgqVdYANKjmT78X/wzhLz42z8wo26mucPt0xl5UUII0HDKadRRqpfNbXXHwVw4I 6X8WBoyWlGus56cGyOOoul7zokVYTl3fGE3vDLF6AKUCB+3uRpE= =futH -----END PGP SIGNATURE----- --kuGjWJaKegyCNzuRL9CzladtYkEpyPgNl-- From nobody Tue Apr 17 03:02: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 5E48512D969; Tue, 17 Apr 2018 03:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 sYc7UUAa7YRA; Tue, 17 Apr 2018 03:02:41 -0700 (PDT) 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 5870012D779; Tue, 17 Apr 2018 03:02:41 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56] (unknown [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56]) (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 DE1EBAE8D8; Tue, 17 Apr 2018 12:02:38 +0200 (CEST) To: Eric Rescorla , Peter Saint-Andre Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: Date: Tue, 17 Apr 2018 03:02:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m94vs86lfj5OjTdRIFDz8QZiMGYdMacl9" Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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, 17 Apr 2018 10:02:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m94vs86lfj5OjTdRIFDz8QZiMGYdMacl9 Content-Type: multipart/mixed; boundary="IvgNIkT3boszypQnuEpfZFm1rJe1brc9I"; protected-headers="v1" From: Marc Petit-Huguenin To: Eric Rescorla , Peter Saint-Andre Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org Message-ID: Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --IvgNIkT3boszypQnuEpfZFm1rJe1brc9I Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/16/2018 08:12 PM, Eric Rescorla wrote: > On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre > wrote: >=20 >> Hi Marc, a few further comments inline. >> >> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >>> Hi Peter, >>> >>> Thanks for the review and sorry for the delay in responding, I was >> traveling for the last 4 weeks. >>> >>> See my responses inline. >>> >>> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>>> Reviewer: Peter Saint-Andre >>>> Review result: Ready with Nits >>>> >> >> >> >>>> The first paragaraph of Section 6.2.3 restates recommendations from = RFC >>>> 7525; why not simply reference that specification? >>> >>> The original text in RFC5389 said this: >>> >>> " When STUN is run by itself over TLS-over-TCP, the >>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >>> minimum. [...]" >>> >>> The new text is an attempt at updating it in the same spirit of givin= g >> minimal instructions and complementing them with a reference to RFC 75= 25 - >> which was the reason for the reference to RFC 7525 there. >>> >>> So I kept the text there, followed by the following paragraph, in >> addition of moving the original last paragraph in the Security >> Consideration section: >>> >>> " These recommendations are just a part of the the recommendations in= >>> [RFC7525] that implementations and deployments of a STUN usage usin= g >>> TLS or DTLS SHOULD follow." >> >> I would instead suggest that we do something like Section 2 of RFC 759= 0 >> for XMPP: >> >> The best current practices documented in the "Recommendations for >> Secure Use of TLS and DTLS" [RFC7525] are included here by referenc= e. >> Instead of repeating those recommendations here, this document most= ly >> provides supplementary information regarding secure implementation >> and deployment of XMPP technologies. >> >> Here's the rationale: RFC 7525 is likely to be updated/replaced more >> quickly than STUNbis. If STUNbis recommends a particular cipher suite >> that 7525bis stops recommending, in the absence of STUNter will STUN >> implementations keep following STUNbis or will they upgrade to whateve= r >> 7525bis recommends? I suggest it will be the former, which is not what= >> we want. >> >=20 > I forgot about this in my review, but you should also profile ciphers f= or > TLS 1.3. >=20 > -Ekr >=20 Do you have any suggestion for these, or a pointer to a document that I c= an use to find these? Thanks. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --IvgNIkT3boszypQnuEpfZFm1rJe1brc9I-- --m94vs86lfj5OjTdRIFDz8QZiMGYdMacl9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrVxj0ACgkQKcRFldZq fsTh9xAAzQyZk9dku3LN3poVPDQjWP31jKLaa8KEUESMU/i9te5w8YFcBOStsVMy SmypWXkWRTpNEIAnHU4Y0rWzjctrYuS8vq4MMGBKG/litcFUd0zI4x/0OSHQGi8X Fww0a8GEC85VD+G5Dm+kcgQyiJfIkptiGLP1zlFfpGklTrohqCpBorburKdOagyX ijYTGOGjCKYOqRTrcEO5aavrCFLI93xqvUv/YM2G9NY9rvR574KN3lkDlQQFQzOF nOPOVlO/dgVz/f/6xGr62r6gjJ+DcNXv6bzu8kqBJQkaIayEci+5wZTTd0a1ZvlN P2X5eexEJxr1Uf/p9qsOIu5lol8fGMSEPu/kwSpYa0FOEUA6wEvhFaogYkjGv5a/ j3pzMqBuMVTegu7wJEhFcD7dO+silAz/xZ8KUkF2z1t1x6B4pVmbBLYC0EXfVS2B tRjcJMSZDLevD9fOS6rWKj7fiwBl+xgqqV2Cjvlhm7USXrHoeoojz8kSuNJHQFkq dZuo514bqDkSX8N3+X/EbcIAHl4qFo5Yn2vZlizcVCBZjkLb+E/U9cJslIOztE/2 peglVe+N5PfbvdCrObKb0EJuy1AgTwSaSEZnfp/SnZQujsgZFVv5p1BvTMlSDL0C 3HNfDg1iRKHbo5qGQSpCg0DVxGLPchnNphITIzZjgaKHqrZUTGI= =WVuG -----END PGP SIGNATURE----- --m94vs86lfj5OjTdRIFDz8QZiMGYdMacl9-- From nobody Tue Apr 17 08:11: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 549D2126C2F for ; Tue, 17 Apr 2018 08:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 NZnEhGJxGbjl for ; Tue, 17 Apr 2018 08:11:33 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 6B04B126B6E for ; Tue, 17 Apr 2018 08:11:31 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id n81-v6so9937603ita.1 for ; Tue, 17 Apr 2018 08:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=sJkXUTBXGjPk3Ho8T8cgHrXWxbFhVPamFiAhcv/PcTA=; b=QDeeUZT5j4AY+z0AcHtGQBvFkcLMAoLZ2bgCU6VaXg423nEn/vF3xuBbSiqqtvXFom S44oHgAqxKqcR6e3QiOrPIH5IndgPAXAcW/0TnJmjsvYrQDPo4zOXkKFXr4Q9J5GfitA aL7CKMpDscoDzrK7uSZil7ubV1+AfaMPOoDrQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=sJkXUTBXGjPk3Ho8T8cgHrXWxbFhVPamFiAhcv/PcTA=; b=D7gnz23eh0dl9IU7pk/p5biltPo7DZBd6FcABB5QPRAg3auxQ8s2Os/TdiuUlskowu hh0P34kymxrDlLtPKkIdbOhAawXmysKM4LgmPYORhe34VBHTtxlg6ThCAhpsivLRvAB7 HdmttKtK7QK1HmWBQu/ZhTbf9kdn2NshY5V9GyKuu78Jndqa6kKJ8/nF3j1oiLdRcJA8 gASNVoC/6fcYDAhb6T62NLYUhqPRjJY3Lm8gix+tyxsAEEgFdI5nT3VqL9O+yLqvDg3B ZDKiofSSUcRUFn+bAWF94Nz4zlpnq+0QSECbsWilGDYw347ERJslBkkgTZfTl+quSE14 gX2Q== X-Gm-Message-State: ALQs6tBVZ+17q8U6PyqY7fYvDaXLhotqZNf3d4NjDOueZXMIZIGlMP8u Y0IGuFandvfaHL7vSeP/cKmNPA== X-Google-Smtp-Source: AIpwx49cYMRRzaUGTjQ9/+2HFCbBc1wCdD0uO3/epGbl/xfd0XUJqxBczqWUrnkdtHPdtv/3+/NVmw== X-Received: by 2002:a24:7b52:: with SMTP id q79-v6mr1470247itc.133.1523977890680; Tue, 17 Apr 2018 08:11:30 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id n67sm536303ioe.20.2018.04.17.08.11.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 08:11:29 -0700 (PDT) To: Marc Petit-Huguenin , Eric Rescorla Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Tue, 17 Apr 2018 09:11:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NuKo0xXfEVPVs8NxhRQwahgAzEn0HW3RQ" Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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, 17 Apr 2018 15:11:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NuKo0xXfEVPVs8NxhRQwahgAzEn0HW3RQ Content-Type: multipart/mixed; boundary="uwDOAXETWazvkzTXacLfdYdapW8huEFyf"; protected-headers="v1" From: Peter Saint-Andre To: Marc Petit-Huguenin , Eric Rescorla Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org Message-ID: Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --uwDOAXETWazvkzTXacLfdYdapW8huEFyf Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/17/18 4:02 AM, Marc Petit-Huguenin wrote: >=20 > On 04/16/2018 08:12 PM, Eric Rescorla wrote: >> On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre >> wrote: >> >>> Hi Marc, a few further comments inline. >>> >>> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >>>> Hi Peter, >>>> >>>> Thanks for the review and sorry for the delay in responding, I was >>> traveling for the last 4 weeks. >>>> >>>> See my responses inline. >>>> >>>> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>>>> Reviewer: Peter Saint-Andre >>>>> Review result: Ready with Nits >>>>> >>> >>> >>> >>>>> The first paragaraph of Section 6.2.3 restates recommendations from= RFC >>>>> 7525; why not simply reference that specification? >>>> >>>> The original text in RFC5389 said this: >>>> >>>> " When STUN is run by itself over TLS-over-TCP, the >>>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >>>> minimum. [...]" >>>> >>>> The new text is an attempt at updating it in the same spirit of givi= ng >>> minimal instructions and complementing them with a reference to RFC 7= 525 - >>> which was the reason for the reference to RFC 7525 there. >>>> >>>> So I kept the text there, followed by the following paragraph, in >>> addition of moving the original last paragraph in the Security >>> Consideration section: >>>> >>>> " These recommendations are just a part of the the recommendations i= n >>>> [RFC7525] that implementations and deployments of a STUN usage usi= ng >>>> TLS or DTLS SHOULD follow." >>> >>> I would instead suggest that we do something like Section 2 of RFC 75= 90 >>> for XMPP: >>> >>> The best current practices documented in the "Recommendations for >>> Secure Use of TLS and DTLS" [RFC7525] are included here by referen= ce. >>> Instead of repeating those recommendations here, this document mos= tly >>> provides supplementary information regarding secure implementation= >>> and deployment of XMPP technologies. >>> >>> Here's the rationale: RFC 7525 is likely to be updated/replaced more >>> quickly than STUNbis. If STUNbis recommends a particular cipher suite= >>> that 7525bis stops recommending, in the absence of STUNter will STUN >>> implementations keep following STUNbis or will they upgrade to whatev= er >>> 7525bis recommends? I suggest it will be the former, which is not wha= t >>> we want. >>> >> >> I forgot about this in my review, but you should also profile ciphers = for >> TLS 1.3. >> >> -Ekr >> >=20 > Do you have any suggestion for these, or a pointer to a document that I= can use to find these? Off-topic: it sounds like we might need to start work on 7525bis... Peter --uwDOAXETWazvkzTXacLfdYdapW8huEFyf-- --NuKo0xXfEVPVs8NxhRQwahgAzEn0HW3RQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrWDqAACgkQZWGMGH9o FKkfjhAA5MH1jh3xHiutIzQIyy9RPTCbBdLJSLNKcZ9EhPhyuL9cvSRzrthNWv6i QgVlKmpDF5DnNQ52HieifRuEFmzApB05pMlwflYvr2X7GtSnvINr0y6KaVbAd8GW 38tf9WOvOUvW3dL83EObi192ugZ8wONPd4l4+qIyT9eiBg7I0gtaYT+yErb44lf7 n1UsoPcNZoHwgLll0xlsDuNM2OCJYd51ofHKBrUwaHy6rLKTMmPX+MTj1YKJBpBz uGWSfGVXZHOMBMUbyqx2Ko0nrNtFlvjxZWWfR8G5uZsOuzMp3wOWfntIbd5HN9VI o53+y4vOL8TErZfpYzzKGKd62dfsYn3/4lR5k8frCRywhynWwhSJ4BKokA9nKJ6R XfVeiNDTRwNeqYIfo/Uvq7CK2xAWeYZYftyjSm/Ysv9G+6CJEVFvz33W0H7NqhTx GOymv4VKcxZ8ekj42K+uczKVIn+jusr6AikjUgftQHJWQjZwj1+on2YEp2dutEY+ Ac931DfqXM/Appxg0sfKScAoGWk++LFmHqUzTYOfrfwTaSBb3ytJNhwxfZ4yVh3+ bVkKCCng48IHxaK1/Syu1k9nYie1Zzfo8IsNfHnmTwBswI45uuw94uMXiVOa9rwW xE/myVUoKr8fhpTiACIxBSSZuBo8ini9395bh+NgBYKTCyvDV8o= =y/mV -----END PGP SIGNATURE----- --NuKo0xXfEVPVs8NxhRQwahgAzEn0HW3RQ-- From nobody Tue Apr 17 12:44:04 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 36EA0126D73 for ; Tue, 17 Apr 2018 12:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 hvMpccfHvyQR for ; Tue, 17 Apr 2018 12:44:00 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A1E126CC4 for ; Tue, 17 Apr 2018 12:43:59 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([81.249.206.57]) by mwinf5d23 with ME id bXjv1x00T1Eq75t03XjwVE; Tue, 17 Apr 2018 21:43:57 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Tue, 17 Apr 2018 21:43:57 +0200 X-ME-IP: 81.249.206.57 To: Marc Petit-Huguenin Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> Date: Tue, 17 Apr 2018 21:43:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] [art] Artart telechat review of draft-ietf-tram-stunbis-16 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, 17 Apr 2018 19:44:02 -0000 Hi Marc, >>> So I kept the text there, followed by the following paragraph, >>> in addition of moving the original last paragraph in the Security >>> Consideration section: >>> >>> " These recommendations are just a part of the the recommendations in >>> [RFC7525] that implementations and deployments of a STUN usage using >>> TLS or DTLS SHOULD follow." >> >> I would instead suggest that we do something like Section 2 of RFC 7590 >> for XMPP: >> >> The best current practices documented in the "Recommendations for >> Secure Use of TLS and DTLS" [RFC7525] are included here by reference. >> Instead of repeating those recommendations here, this document mostly >> provides supplementary information regarding secure implementation >> and deployment of XMPP technologies. >> >> Here's the rationale: RFC 7525 is likely to be updated/replaced more >> quickly than STUNbis. If STUNbis recommends a particular cipher suite >> that 7525bis stops recommending, in the absence of STUNter will STUN >> implementations keep following STUNbis or will they upgrade to whatever >> 7525bis recommends? I suggest it will be the former, which is not what >> we want. > > All right, makes sense. I'll add something like this on my next > round of reviews, most likely this Friday. If you're going to add some wording about including TLS best current practices, maybe you could re-use what we came up with during final RFC edition of RFC 8143 : 3. Recommendations The best current practices documented in [BCP195] apply here. Therefore, NNTP implementations and deployments compliant with this document are REQUIRED to comply with [BCP195] as well. Instead of repeating those recommendations here, this document mostly provides supplementary information regarding secure implementation and deployment of NNTP technologies. Notably, the RFC Editor prefers referencing RFC 7525 as BCP 195 even though there currently is only one RFC in this BCP series. As other RFCs may be added in BCP 195, and we want to follow all best practices that apply, the reference should be the BCP series. -- Julien ÉLIE « – C'est joli cette avenue le long de la mer… Ça s'appelle comment ? – La promenade des Bretons. » (Astérix) From nobody Tue Apr 17 23:03: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 8F44712D77B; Tue, 17 Apr 2018 23:03:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2018 23:03:08 -0700 Archived-At: Subject: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) 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: Wed, 18 Apr 2018 06:03:09 -0000 Adam Roach has entered the following ballot position for draft-ietf-tram-stunbis-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to everyone who worked on this revision of the STUN protocol. Thanks in particular to the ARTART reviewer and to the authors for actively engaging on the points he raised. I have one concern about interoperability and another about the IANA changes that I believe require changes to the document prior to publication. §14.2: > X-Port is computed by taking the mapped port in host byte order, > XOR'ing it with the most significant 16 bits of the magic cookie, and > then the converting the result to network byte order. If the IP > address family is IPv4, X-Address is computed by taking the mapped IP > address in host byte order, XOR'ing it with the magic cookie, and > converting the result to network byte order. If the IP address > family is IPv6, X-Address is computed by taking the mapped IP address > in host byte order, XOR'ing it with the concatenation of the magic > cookie and the 96-bit transaction ID, and converting the result to > network byte order. The discussion of performing operations "in host byte order" is very confusing, and seems likely to cause issues communicating between machines of different endianness. As an implementor, based on this description, I cannot tell whether, given a port of 0x1234 (and operating on a little-endian machine), I'm supposed to do: Port (host order): 34 12 Magic Cookie Prefix: 21 12 Result (host order): 15 00 X-Port (net order): 00 15 or: Port (host order): 34 12 Magic Cookie Prefix: 12 21 Result (host order): 26 33 X-Port (net order): 33 26 One of these is clearly wrong. I think it's the first one, but I *also* think that the first one is the most straightforward interpretation of the quoted paragraph. The following would seem to be a complete description of the operation without introducing possible confusion about the difference between host and network order: X-Port is computed by XOR'ing the mapped port with the most significant 16 bits of the magic cookie. If the IP address family is IPv4, X-Address is computed XOR'ing the mapped IP with the magic cookie. If the IP address family is IPv6, X-Address is computed by XOR'ing the mapped IP address with the concatenation of the magic cookie and the 96-bit transaction ID. In all cases, the XOR operation works on its inputs in network byte order (that is, the order they will be encoded in the message). This makes it clear that the proper operation is: Port: 12 34 Magic Cookie Prefix: 21 12 Result / X-Port: 33 26 --------------------------------------------------------------------------- §17.3.1: > IANA is requested to update the names for attributes 0x0002, 0x0003, > 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from RFC 5389 > to RFC-to-be for the following STUN methods: ... > 0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUEST) The attribute 0x0003 is registered by RFC 5780, and should not be removed by this document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §3: This is almost, but not quite, the boilerplate defined by RFC 8174. Please update to match the text in RFC 8174. --------------------------------------------------------------------------- §5: > server to detect if the client will understand certain attributes > that were added in this revised specification. This is a *bit* misleading, as these attributes were actually added in RFC 5389. Consider: "...that were added to STUN by [RFC5389]." --------------------------------------------------------------------------- §6.1: > If the agent is sending a request, it SHOULD add a SOFTWARE attribute > to the request. I believe this would benefit from a pointer to the security section; e.g.: "Note that the inclusion of a SOFTWARE attribute may have security implications; see Section 15.1.2 for details." --------------------------------------------------------------------------- §6.2: > STUN may be used > with anycast addresses, but only with UDP and in usages where > authentication is not used. This bit of operational advice seems out of place in the middle of an implementation discussion, and is quite likely to be missed by its intended audience. Consider relocating it to an "Operational Considerations" section. --------------------------------------------------------------------------- §6.2.1: > As with TCP, the usage of Karn's > algorithm is RECOMMENDED [KARN87]. This normative language means that [KARN87] needs to be a normative reference. --------------------------------------------------------------------------- §6.2.3 says: > Alternatively, a > client MAY be configured with a set of IP addresses that are trusted; > if a certificate is received that identifies one of those IP > addresses, the client considers the identity of the server to be > verified. Presumably, this means the server supplies a certificate with SubjectAltName containing an iPAddress? Please add text to clarify whether that's the intention. If that *is* the intended meaning, then this behavior in §8.1 seems unnecessarily restrictive: > A "stuns" URI > containing an IP address MUST be rejected, unless the domain name is > provided by the same mechanism that provided the STUN URI, and that > domain name can be passed to the verification code. Presumably, this is done because certs with iPAddress-form SubjectAltNames are pretty rare (although CAB Forum baseline requirements do explicitly allow their issuance) -- but if the text in §6.2.3 is based on allowing the use of such certs in a TURN deployment, then it seems that URI resolution should be also. --------------------------------------------------------------------------- §9.1.3: > If the MESSAGE- > INTEGRITY-SHA256 attribute is not present, and using the same > password, compute the value for the message integrity as described > in Section 14.5. I can't figure out what is meant by "and using the same password" here. The structure of the sentence would imply that the subject of "using" is "attribute" (the one that is not present), but that doesn't make sense. Is it supposed to be something like this? If the MESSAGE-INTEGRITY-SHA256 attribute is not present, compute the value for the message integrity as described in Section 14.5, using the same password as would have been used for MESSAGE-INTEGRITY-SHA256. --------------------------------------------------------------------------- §9.1.5: > A client sending subsequent requests to the same server MUST send > only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute > that matches the attribute that was received in the response to the > initial request. How long does it continue to do so? It seems sensible to do this for the length of validity of the credentials (and no longer) -- and probably even scoped to the credentials -- but the document really should call that out explicitly. --------------------------------------------------------------------------- §9.2.2: > The structure of the key when used with long-term credentials > facilitates deployment in systems that also utilize SIP [RFC3261]. > 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. Suggest adding something like: "For example, this mechanism can be used with the authentication extensions defined in [RFC5090]." --------------------------------------------------------------------------- §9.2.3.2: > Once a request/response transaction has completed successfully, the The use of "successfully" here is kind of confusing, since the transaction in question was completed with an Error Response. Suggest dropping "successfully". --------------------------------------------------------------------------- §9.2.4: > o If the NONCE is no longer valid, the server MUST generate an error > response with an error code of 438 (Stale Nonce). This response > MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and > SHOULD NOT include the USERNAME, USERHASH attribute, The NONCE > attribute value MUST be valid. Nit: The comma before the final "The" should be a period. --------------------------------------------------------------------------- §9.2.4: > USERHASH attribute. The response MAY include a MESSAGE-INTEGRITY > or MESSAGE-INTEGRITY-SHA256 attribute, using the previous password > to calculate it. I think this means to say "using the previous key," right? --------------------------------------------------------------------------- §14: > The > padding bits are ignored, and may be any value. This seems to be encouraging implementors to use uninitialized memory for these bits, which could be a security issue. It would be far safer to do the more traditional "must be set to zero on sending, must be ignored by receiver" thing here. --------------------------------------------------------------------------- §14.5: > Petit-Huguenin, et al. Expires September 6, 2018 [Page 40] > > Internet-Draft Session Traversal Utilities for NAT (STUN) March 2018 > Similarly, when validating the MESSAGE-INTEGRITY, the length field in This appears to be an errant header/footer pair. Note that the correctly-formatted footer for page 40 appears several paragraphs later. --------------------------------------------------------------------------- §14.7: > The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which > has a generator polynomial of > x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. Please correct the polynomial representation: x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1. --------------------------------------------------------------------------- §14.8: > The reason phrase is meant for user consumption This is a very tricky assertion to maintain, unless you want to start working with language tags and reason phrase localization. I think you're far safer saying something like "The reason phrase is meant for diagnostic purposes." I would not encourage implementations to just display its contents to users without any localization discussion. --------------------------------------------------------------------------- §15.2.4: It's probably worth additionally noting that this attack can be trivially launched by the STUN server itself -- so users of STUN servers should have the same level of trust in them as any other node that can insert themselves into the communication flow. --------------------------------------------------------------------------- §15.3: I'm surprised that there is no plan in here for cryptoagility of the USERHASH TLV. While a practical preimage attack on SHA-256 seems pretty implausible today, it would be nice to know that we have a remedy if we ever decide that we need to change things. From nobody Tue Apr 17 23:11: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 C7F1C12702E; Tue, 17 Apr 2018 23:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMX-cYbfdwRN; Tue, 17 Apr 2018 23:11:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BE76C12D77B; Tue, 17 Apr 2018 23:11:43 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3I6BfJP040988 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Apr 2018 01:11:42 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org References: <152390695800.19624.250040937113641569.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 18 Apr 2018 01:11:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152390695800.19624.250040937113641569.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram?= =?utf-8?q?-stunbis-16=3A_=28with_COMMENT=29?= 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, 18 Apr 2018 06:11:45 -0000 On 4/16/18 2:29 PM, Mirja Kühlewind wrote: > 8) sec 17.6: Isn't "stuns 5349/upd" used for DTLS? If so, it should be > registered! Just because I had the same question and chased it down: it was (re-)registered by RFC 7350, and so does not need updating. /a From nobody Wed Apr 18 09:29:23 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 D8BA31242F7; Wed, 18 Apr 2018 09:29:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152406896286.13830.7440801444130192741.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2018 09:29:22 -0700 Archived-At: Subject: [tram] Alexey Melnikov's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) 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: Wed, 18 Apr 2018 16:29:23 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-tram-stunbis-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to discuss several issues with the document (which look easy to fix to me) before recommending its approval for publication as an RFC: 1) 14.3. USERNAME The USERNAME attribute is used for message integrity. It identifies the username and password combination used in the message-integrity check. The value of USERNAME is a variable-length value containing the authentication username. It MUST contain a UTF-8 [RFC3629] encoded sequence of less than 509 bytes, and MUST have been processed using the OpaqueString profile [RFC8265]. I am trying to understand if there was a particular reason why you didn't use UsernameCasePreserved (or its case insensitive alternative) profile here which was specifically designed for usernames? A compliant implementation MUST be able to parse UTF-8 encoded sequence of less than 763. I am confused by this statement: you already have 509 bytes above. Is "no" missing above? 14.4. USERHASH The USERHASH attribute is used as a replacement for the USERNAME attribute when username anonymity is supported. The value of USERHASH has a fixed length of 32 bytes. The username and the realm MUST have been processed using the OpaqueString profile [RFC8265] before hashing. As above: why didn't you use UsernameCasePreserved profile which was specifically designed for usernames? 2) 14.9. REALM The REALM attribute may be present in requests and responses. It contains text that meets the grammar for "realm-value" as described in [RFC3261] but without the double quotes and their surrounding whitespace. That is, it is an unquoted realm-value (and is therefore a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 509 bytes when encoding them and a long as 763 bytes when decoding them), (Here and similar text in several other sections) Can you please elaborate on how you came up with values 509 and 763? And why you need more space for decoding than for encoding of UTF-8. and MUST have been processed using the OpaqueString profile [RFC8265]. 3) 14.16. ALTERNATE-DOMAIN The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be Ekr already pointed this out, but I want to expand on this: you need to say whether this allows U-label (which are UTF-8) or A-labels (which are ASCII only). If you only allow Punycode encoded A-labels, this field doesn't need to be UTF-8, it only need to be ASCII. As far as I remember ASCII domain names are limited to 255 bytes. as long as 509 bytes when encoding them and as long as 763 bytes when decoding them). 4) 10. ALTERNATE-SERVER Mechanism If the transport protocol uses TLS or DTLS, then the client looks for an ALTERNATE-DOMAIN attribute. If the attribute is found, the domain MUST be used to validate the certificate using the recommendations in [RFC6125]. When you reference RFC 6125 you need to provide more details: a) Are you expecting support for DNS-ID, CN-ID or both? I assume you don't support SRV-ID/URI-ID (saying so explicitly would be great too). b) Are you expected to allow wildcards in DNS-IDs/CN-IDs? If yes, you need to say so. There is one more reference to RFC 6125 in the document, you should make a similar change there as well. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am agreeing with DISCUSS/comments from Adam. Additionally, I have the following comments: 9.2.4. Receiving a Request o If the value of the USERNAME or USERHASH attribute is not valid, the server MUST generate an error response with an error code of 401 (Unauthenticated). This response MUST include a REALM value. It is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server. You include this sentence here and at the beginning of this section, but not above (in at least 2 other places) where REALM is also mentioned? Just mention the advice once earlier in this section? 14.10. NONCE Note that this means that the NONCE attribute will not contain actual the surrounding quote characters. This doesn't look right. Either drop "actual" or move it after "the"? From nobody Wed Apr 18 18:10:43 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 A7315126C89; Wed, 18 Apr 2018 18:10:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152410023763.28841.5479872591399614102.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2018 18:10:37 -0700 Archived-At: Subject: [tram] Benjamin Kaduk's No Record on draft-ietf-tram-stunbis-16: (with COMMENT) 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: Thu, 19 Apr 2018 01:10:38 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-tram-stunbis-16: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting No Objection and not DISCUSS because no individual item rises quite to that level of criticality, but there still are quite a number of things that ought to be addressed prior to publication. In addition to the excellent points raised in the secdir review (which are mostly addressed but only in the editor's copy?), I would call out a few more key observations: If I understand correctly, the server's PASSWORD-ALGORITHMS array from the response are echoed back by the client in the subsequent request in order to provide downgrade protection -- the initial response is at least sometimes not authenticated, and by having the client repeat it back under an authenticated scheme, the server can detect if the list was tampered to remove any new, stronger, algorithms. This is probably an important enough concept to be called out explicitly, either where the behavior is described or in Section 9.2.1 ("Bid Down Attack Prevention"). Section 8.1 has some text that could be read as requiring a STUN client to implement dual-stack IPv4/IPv6, which presumably is not the intention: In addition, instead of querying either the A or the AAAA resource records for a domain name, the client MUST query both and try the requests with all the IP addresses received, as specified in [RFC8305]. There are still some places where the text talks about MESSAGE-INTEGRITY when it really means "message integrity protection" (i.e., either the SHA1 or SHA-256 variants, for now); I've attempted to note them in the notes below. There is text in both Sections 9.1 and 9.2 that talks of replay protection being provided, by the time-limited nature of the short-term credentials or the nonce for long-term credentials. This seems to only, strictly speaking, be true if any given password/nonce can only be used once, but for the short-term credentials the password is used for the duration of the "session-equivalent", and for the long-term credentials a nonce can be reused for some amount of time as well. So while these are both replay countermeasures that can limit replay attacks, it seems a stretch to claim that they prevent replay attacks (entirely). The Stale Nonce behavior seems potentially worrisome, in that it opens up a side channel for a distinguishing attack, between a 401 and 438 response. (That is, "password correct" vs. "password incorrect".) The impact seems rather muted, though, since the gain to the attacker is to be able to precompute a bunch of requests using a nonce of the attacker's choosing and blindly replay the precomputed object against (possibly multiple) servers looking for a guess. The realm and username are still in play, so the scope for the attacker to gain from the precomputation seems limited. (The same level of brute-force guessing can be obtained "live" just by computing the trial responses against a live server, using a valid nonce.) So, while it might be nice to give guidance that 438 should only be used when the server can validate that it did generate the nonce and the nonce was valid "recently", and to treat other cases as authentication failures, it's not clear to me that there's enough of a benefit from the change to make it worth doing. Section 6.2.3 Maybe just cite BCP 195/RFC 7525 instead of inlining requirements? Also, the "client SHOULD verify ..." and "client MUST verify ..." are similar enough that some clarification of certificate vs. identity verification would be in order, if both statements are believed accurate. Section 6.3 [...] Known-but-unexpected attributes SHOULD be ignored by the agent. [...] Why is this not an error? Section 6.3.1, 6.3.2, etc. Should the second paragraph start with "Otherwise, "? Presumably once an error response is sent or processing ceases, processing stops... Section 8.1 [...] A "stuns" URI containing an IP address MUST be rejected, unless the domain name is provided by the same mechanism that provided the STUN URI, and that domain name can be passed to the verification code. "the verifcation code" is probably unnecessarily vague; we're just talking about the (D)TLS SNI and certifciate verification code, right? Section 9.2 [...[ The nonce provides the replay protection. It is a cookie, selected by the server, and encoded in such a way as to indicate a duration of validity or client identity from which it is valid. Is this like a TLS cookie, where only the server needs to know about the internal structure (viz. "encoded" in the above)? If so, the text could probably be more clear. When mentioning just "a message-integrity", maybe forward-ref both versions of it to be more clear that we don't mean just the old one? It's unclear why indications can't use a nonce, if one is known from a previous request/response on the same connection. When encoding the value of 0 for the security feature, it may be worth clarifying that it is still encoded as a 24-bit integer and base64-encoded, though the "13 character string" text ought to make this clear to the reader. Section 9.2.4 * 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). This Note seems a bit odd, since we're predicated on PASSWORD-ALGORITHMS being absent. * 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). Maybe we could be more clear about "the value of the PASSWORD-ALGORITHMS attribute in the message matches the value of the PASSWORD-ALGORITHMS attribute sent in the response that sent the NONCE used with this message"? Section 9.2.5 If the response contains a PASSWORD-ALGORITHMS attribute, the subsequent request MUST be authenticated using MESSAGE-INTEGRITY- SHA256 only. This means "all subsequent requests to this server"? Maybe the wording could be more clear. (It also means that if we get a new scheme when SHA256 is broken, the document introducing it may need to Update this document to remove the MUST.) Also, I think the Security Feature bit is "Password algorithms" plural (in the next paragraph and maybe multiple locations in the document). Section 10 [...] If the transaction uses TLS or DTLS and if the transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute and if the server wants to redirect to a server that uses a different certificate, then it MUST include an ALTERNATE-DOMAIN attribute containing the subjectAltName of that certificate. The (definite article), implying the entire subjectAltName? Or just one name that is contained as a SAN entry? Section 14.8 Need to not just say MESSAGE-INTEGRITY since the SHA256 variant should be fine as well. Section 14.10 Maybe the nonce cookie should get a shout-out here? Section 14.12 Do we need to talk about the padding, since this is the the sole contents of the attribute and the attribute padding suffices? Also, "derive the long-term password" doesn't seem quite right; we're deriving the key from the long-term password, per Section 17.15.1. Section 15.1.2 There is no amplification of the number of packets with this attack (the STUN server sends one packet for each packet sent by the client), though there is a small increase in the amount of data, since STUN responses are typically larger than requests. I usually hear amplification in terms of bytes or bandwidth, not packets. So maybe just "amplification is modest"? Section 15.3 This specification uses both HMAC-SHA1 and HMAC-SHA256 for computation of the message integrity. Could perhaps be reworded, since the number of situations when both are used on the same message is small, and we try to push SHA256 when we can. o STUN Client and Server using the Short Term Credential Mechanism Clients and Servers, plural. Section 17.32. I'm confused why we have MUST-level requirements about using PASSWORD-ALGORITHMS when it is in the comprehension-optional range (e.g., echoing from response to repeated request as in Section 9.2.5). The server cannot actually enforce this MUST when talking to an old client if we want to retain the comprehension-optional semantics, IIUC. Section 17.6 If we're adding support for DTLS-over-udp (per the next section), should we be registering stuns/udp? "password encryption algorithm" is not quite the right statement to make, since we're hashing, not encrypting. From nobody Wed Apr 18 18:56:20 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 D0DD8127333; Wed, 18 Apr 2018 18:56:12 -0700 (PDT) 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, 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=cooperw.in header.b=RRHRHo9Z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mxAmEf7k 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 bCBTE1iUx_M2; Wed, 18 Apr 2018 18:56:09 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406AE1271DF; Wed, 18 Apr 2018 18:56:09 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A64F02106C; Wed, 18 Apr 2018 21:56:08 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 18 Apr 2018 21:56:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=/Ee29HHGChw58tkSfYsIHW6nGY92QyEwJBHkdPY+cck=; b=RRHRHo9Z BvZuw3oL2594cssUayvyiJlrqOkRH7thiKUvOxMCxDoJouI6QMo8mYHUZLQB4F7q jjqEjtZGAM/pHcachrZNgewttmH5siEP3LOdSTlSPerlyz6iQlI8F03+WWCZ/vCl Qi+r53wBU1fzOKiP3q6O9uka7u1z9A+5RQXn3dgpsbJaoB/CFNzp+EpIlbCR7L+F mMLylEJXW8fcLqqbVFk5Yacg38Gl4fS/FnhKeCC18wN0yq+PyY1XNWATWcNwZYUe fJTehQh6QRJ1HVga9HDskkRKov6KQIXaHPMxgp/wh4XdXfbh3Bsq4oXdV77ISgbi W53rhfFAm1Ab0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=/Ee29HHGChw58tkSfYsIHW6nGY92Q yEwJBHkdPY+cck=; b=mxAmEf7kzAhnq9E145kKzseTAJic1XWTF01BzuUk9WhM9 xs8VsUP8I5twekFukW/NPaGKO5IrFtgXvETEU7NRu3grQwxNoIMNxT17BR5pMmGZ D2cwXdC2ZUqLycHW5JXgFMJRdhIE/CiCn01mqAg3WaJ+rFRT0NLOpN7MPbYYe5Hp SsZKLr5kJzl5RoheCv6Na0G70fKHfo0aG3RD3T1xLrVpXoM84nBcBwlnmgFF1p++ Jm1Ty0iGWHtnJoZ0IJWTxou1BMIFl5MXexN1XAYSu8kWk41mzm/Tz8L6aX44Z0hV Hhs2SfBS9BYRLfae/vRwKr9GooCGmGLdRt6H0/AoQ== X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.67]) by mail.messagingengine.com (Postfix) with ESMTPA id EC6D9E4483; Wed, 18 Apr 2018 21:56:07 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E5B8D961-58EC-432A-B12A-130E25C06D00" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Wed, 18 Apr 2018 21:56:07 -0400 Cc: Dale Worley , IETF Gen-ART , draft-ietf-tram-stunbis.all@ietf.org, tram@ietf.org Message-Id: <5D4C0196-8073-4174-A10B-8690637310B8@cooperw.in> References: <152237792217.20556.13689609450529144296@ietfa.amsl.com> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 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, 19 Apr 2018 01:56:13 -0000 --Apple-Mail=_E5B8D961-58EC-432A-B12A-130E25C06D00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dale, thanks for your reviews. Marc, thanks for your response. I have = entered a No Objection ballot. Alissa > On Apr 16, 2018, at 5:49 PM, Marc Petit-Huguenin = wrote: >=20 > Thanks again for the review. Comments inline. >=20 > On 03/30/2018 04:45 AM, Dale Worley wrote: >> Reviewer: Dale Worley >> Review result: Ready with Nits >>=20 >> 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 wait for direction from your >> document shepherd or AD before posting a new version of the draft. >>=20 >> For more information, please see the FAQ at >> . >>=20 >> Document: draft-ietf-tram-stunbis-16 >> Reviewer: Dale R. Worley >> Review Date: 2018-03-29 >> IETF LC End Date: 2018-02-20 >> IESG Telechat date: 2018-04-19 >>=20 >> Summary: >>=20 >> This draft is basically ready for publication, but has nits >> that should be fixed before publication. >>=20 >> The only interesting item concerns section 17.1, where the assignment >> of meanings to bits in the "security feature set" value is different >> from the assignment in -16. This is either non-upward-compatible = with >> -16, or there is an error in either -16 or -17. >>=20 >> = ---------------------------------------------------------------------- >>=20 >> 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. >=20 > I still do not have text about that but, as this is blocking this = response since 2 weeks now, I am releasing it as is and will come back = to that after I process the other reviews that accumulated during my = time traveling around Europe. >=20 >>=20 >> 3. Terminology >>=20 >> This section needs to be updated to reference RFC 8174, including >> updating the paragraph (especially the final two lines) to read as >> specified in RFC 8174: >>=20 >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", >> "MAY", and "OPTIONAL" in this document are to be interpreted as >> described in BCP 14 [RFC2119] [RFC8174] when, and only when, = they >> appear in all capitals, as shown here. >=20 > Updated. >=20 >>=20 >> 6.2.2. Sending over TCP or TLS-over-TCP >>=20 >> o if multiplexing other application protocols over that port, has >> finished using that other protocol, and >>=20 >> The two clauses don't match in grammatical number. This should be >> either >>=20 >> o if multiplexing other application protocols over that port, has >> finished using those other protocols, and >>=20 >> or >>=20 >> o if multiplexing another application protocol over that port, has >> finished using that other protocol, and >=20 > Updated using the former. >=20 >>=20 >> 9.2.4. Receiving a Request >>=20 >> * 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). >>=20 >> There are two places where s/PASSWORD- ALGORITHM/PASSWORD-ALGORITHM/. >=20 > Already fixed following a previous review. >=20 >>=20 >> 14.3. USERNAME >>=20 >> The value of USERNAME is a variable-length value containing the >> authentication username. It MUST contain a UTF-8 [RFC3629] encoded >> sequence of less than 509 bytes, and MUST have been processed using >> the OpaqueString profile [RFC8265]. A compliant implementation = MUST >> be able to parse UTF-8 encoded sequence of less than 763. >>=20 >> The final "763" is grammatically incorrect. I think you intend >> s/763/763 bytes/, to parallel other items. >=20 > Fixed. >=20 >>=20 >> 14.4. USERHASH >>=20 >> userhash =3D SHA-256(Opaque(username) ":" Opaque(realm)) >>=20 >> I believe that this should be >>=20 >> userhash =3D SHA-256(OpaqueString(username) ":" = OpaqueString(realm)) >=20 > Fixed. >=20 >>=20 >> 14.5. MESSAGE-INTEGRITY >>=20 >> Petit-Huguenin, et al. Expires September 6, 2018 [Page 40] >>=20 >> Internet-Draft Session Traversal Utilities for NAT (STUN) March = 2018 >>=20 >> This bit of text appears as body text in the middle of page 40. >=20 > Already fixed following a previous review. >=20 >>=20 >> 14.6. MESSAGE-INTEGRITY-SHA256 >>=20 >> The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA256 >> [RFC2104] of the STUN message. 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 HMAC MUST = NOT >> be truncated below a minimum size of 16 bytes. The value must be = the >> full 32 bytes unless the STUN Usage explicitly specifies that >> truncation is allowed. STUN Usages may specify a minimum length >> longer than 4 bytes. >>=20 >> This seems to be less clear than it could be. (And my apologies, = some >> of the redundancy was my suggestion!) Perhaps this is an = improvement: >>=20 >> The value will be at most 32 bytes, MUST be at least 16 bytes, and >> MUST be a multiple of 4 bytes. The value must be the full 32 bytes >> unless the STUN Usage explicitly specifies that truncation is >> allowed. STUN Usages may specify a minimum length longer than 16 >> bytes. >=20 > Applied. >=20 >>=20 >> 17.1. STUN Security Features Registry >>=20 >> A STUN Security Feature set defines 24 bit as flags. >>=20 >> IANA is requested to create a new registry containing the STUN >> Security Features that are protected by the bid down attack >> prevention mechanism described in section Section 9.2.1. >>=20 >> The initial STUN Security Features are: >>=20 >> Bit 0: Password algorithms >> Bit 1: Username anonymity >> Bit 2-23: Unassigned >>=20 >> Beware that the assignment of features to bits in the security = feature >> value has changed! Bit numbers are assigned from the left/high-order >> end -- see figure 2 in the draft. So the *values* for these bits = are: >>=20 >> 0x400000 Bit 0: Password algorithms >> 0x200000 Bit 1: Username anonymity >>=20 >> But the values assigned in -15 were: >>=20 >> 0x000001: Password algorithms >> 0x000002: Username anonymity >=20 > Hmm, that was not the intent, and not how I read the text. Even in = Figure 2 less significant bits are on the right. So the intent is real = tat bit0=3D0x001, bit1 =3D > 0x002, and so on. All we do is about interoperability, so I added = some text that makes that less ambiguous. >=20 >=20 > --=20 > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org = > Profile: https://www.linkedin.com/in/petithug = >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram = --Apple-Mail=_E5B8D961-58EC-432A-B12A-130E25C06D00 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dale, thanks for your reviews. Marc, thanks = for your response. I have entered a No Objection ballot.

Alissa

On = Apr 16, 2018, at 5:49 PM, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:

Thanks again for the review.  Comments = inline.

On 03/30/2018 04:45 = AM, Dale Worley wrote:
Reviewer: Dale Worley
Review result: Ready with = Nits

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 wait for direction from your
document shepherd or AD before posting a new version of the = draft.

For more information, please see the = FAQ at
<https://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>.
Document:  draft-ietf-tram-stunbis-16
Reviewer:  Dale R. Worley
Review Date: =  2018-03-29
IETF LC End Date:  2018-02-20
IESG Telechat date:  2018-04-19

Summary:

      This draft is basically = ready for publication, but has nits
      that should be fixed = before publication.

The only interesting = item concerns section 17.1, where the assignment
of = meanings to bits in the "security feature set" value is different
from the assignment in -16.  This is either = non-upward-compatible with
-16, or there is an error in = either -16 or -17.

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

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.

I still do not have = text about that but, as this is blocking this response since 2 weeks = now, I am releasing it as is and will come back to that after I process = the other reviews that accumulated during my time traveling around = Europe.


3. =  Terminology

This section needs to be = updated to reference RFC 8174, including
updating the = paragraph (especially the final two lines) to read as
specified in RFC 8174:

     The key words "MUST", "MUST = NOT", "REQUIRED", "SHALL", "SHALL
     NOT", "SHOULD", "SHOULD NOT", = "RECOMMENDED", "NOT RECOMMENDED",
     "MAY", and "OPTIONAL" in this = document are to be interpreted as
     described in BCP 14 [RFC2119] = [RFC8174] when, and only when, they
     appear in all capitals, as = shown here.

Updated.


6.2.2.  Sending over TCP or TLS-over-TCP
  o  if multiplexing other application = protocols over that port, has
     finished using that other = protocol, and

The two clauses don't match = in grammatical number.  This should be
either

  o  if multiplexing other = application protocols over that port, has
     finished using those other = protocols, and

or

  o  if multiplexing another application = protocol over that port, has
     finished using that other = protocol, and

Updated using the former.


9.2.4.  Receiving a 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-ALGORI= THMS attribute did not contain MD5, this will
        result in a = 400 Bad Request in a later step below).

There= are two places where s/PASSWORD- ALGORITHM/PASSWORD-ALGORITHM/.

Already fixed following a previous = review.


14.3. =  USERNAME

  The value of = USERNAME is a variable-length value containing the
  authentication username.  It MUST contain a = UTF-8 [RFC3629] encoded
  sequence of less than = 509 bytes, and MUST have been processed using
  the OpaqueString profile [RFC8265].  A = compliant implementation MUST
  be able to parse = UTF-8 encoded sequence of less than 763.

The = final "763" is grammatically incorrect.  I think you intend
s/763/763 bytes/, to parallel other items.

Fixed.


14.4.  USERHASH

  userhash =3D SHA-256(Opaque(username) ":" = Opaque(realm))

I believe that this should = be

  userhash =3D = SHA-256(OpaqueString(username) ":" OpaqueString(realm))

Fixed.


14.5.  MESSAGE-INTEGRITY

  Petit-Huguenin, et al.  Expires September 6, = 2018 [Page 40]

  Internet-Draft = Session Traversal Utilities for NAT (STUN) March 2018

This bit of text appears as body text in the middle of page = 40.

Already fixed following a previous = review.


14.6. =  MESSAGE-INTEGRITY-SHA256

  The MESSAGE-INTEGRITY-SHA256 attribute contains = an HMAC-SHA256
  [RFC2104] of the STUN message. =  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 HMAC MUST NOT
  be truncated below a = minimum size of 16 bytes.  The value must be the
  full 32 bytes unless the STUN Usage explicitly = specifies that
  truncation is allowed. =  STUN Usages may specify a minimum length
  longer than 4 bytes.

This seems to be less clear than it could be.  (And my = apologies, some
of the redundancy was my suggestion!) =  Perhaps this is an improvement:

  The value will be at most 32 bytes, MUST be at = least 16 bytes, and
  MUST be a multiple of 4 = bytes.  The value must be the full 32 bytes
  unless the STUN Usage explicitly specifies that = truncation is
  allowed.  STUN Usages may = specify a minimum length longer than 16
  bytes.

Applied.


17.1.  STUN Security Features = Registry

  A STUN Security = Feature set defines 24 bit as flags.

  IANA is requested to create a new registry = containing the STUN
  Security Features that are = protected by the bid down attack
  prevention = mechanism described in section Section 9.2.1.

  The initial STUN Security Features are:

  Bit 0: Password algorithms
  Bit 1: Username anonymity
  Bit 2-23: Unassigned

Beware that the assignment of features to bits in the = security feature
value has changed!  Bit numbers are = assigned from the left/high-order
end -- see figure 2 in = the draft.  So the *values* for these bits are:

0x400000   Bit 0: Password algorithms
0x200000   Bit 1: Username anonymity

But the values assigned in -15 were:

  0x000001: Password algorithms
  0x000002: Username anonymity

Hmm, that was not the intent, and not how I read = the text. Even in Figure 2 less significant bits are on the right. =  So the intent is real tat bit0=3D0x001, bit1 =3D
0x002, and so on. =  All we do is about interoperability, so I added some text that = makes that less ambiguous.


-- 
Marc = Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

_______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

= --Apple-Mail=_E5B8D961-58EC-432A-B12A-130E25C06D00-- From nobody Fri Apr 20 02:32:45 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 AE7F3126B6D; Fri, 20 Apr 2018 02:32:43 -0700 (PDT) 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.78.0 Auto-Submitted: auto-generated Precedence: bulk Cc: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren , tasveren@rbbn.com, iesg-secretary@ietf.org, Gonzalo Camarillo Message-ID: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com> Date: Fri, 20 Apr 2018 02:32:43 -0700 Archived-At: Subject: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07 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, 20 Apr 2018 09:32:43 -0000 Gonzalo Camarillo has requested publication of draft-ietf-tram-stun-pmtud-07 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-stun-pmtud/ From nobody Sat Apr 21 14:03:16 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 CFC7B12DA12; Sat, 21 Apr 2018 14:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 odj9VI5Hz6Zg; Sat, 21 Apr 2018 14:02:54 -0700 (PDT) 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 328811242F5; Sat, 21 Apr 2018 14:02:54 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7] (unknown [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7]) (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 A6853AE844; Sat, 21 Apr 2018 23:02:50 +0200 (CEST) To: =?UTF-8?Q?Julien_=c3=89LIE?= Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> From: Marc Petit-Huguenin Message-ID: Date: Sat, 21 Apr 2018 14:02:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uveg8IQlS7aDvv6qn8mVKtqgZcmr5zzAw" Archived-At: Subject: Re: [tram] [art] Artart telechat review of draft-ietf-tram-stunbis-16 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: Sat, 21 Apr 2018 21:02:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uveg8IQlS7aDvv6qn8mVKtqgZcmr5zzAw Content-Type: multipart/mixed; boundary="w0ECpTSTKe1lsKmqib92dfauL32s86Ucz"; protected-headers="v1" From: Marc Petit-Huguenin To: =?UTF-8?Q?Julien_=c3=89LIE?= Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: [tram] [art] Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> In-Reply-To: <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> --w0ECpTSTKe1lsKmqib92dfauL32s86Ucz Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/17/2018 12:43 PM, Julien =C3=89LIE wrote: > Hi Marc, >>>> So I kept the text there, followed by the following paragraph, >>>> in addition of moving the original last paragraph in the Security >>>> Consideration section: >>>> >>>> " These recommendations are just a part of the the recommendations i= n >>>> =C2=A0=C2=A0 [RFC7525] that implementations and deployments of a STU= N usage using >>>> =C2=A0=C2=A0 TLS or DTLS SHOULD follow." >>> >>> I would instead suggest that we do something like Section 2 of RFC 75= 90 >>> for XMPP: >>> >>> =C2=A0=C2=A0=C2=A0 The best current practices documented in the "Reco= mmendations for >>> =C2=A0=C2=A0=C2=A0 Secure Use of TLS and DTLS" [RFC7525] are included= here by reference. >>> =C2=A0=C2=A0=C2=A0 Instead of repeating those recommendations here, t= his document mostly >>> =C2=A0=C2=A0=C2=A0 provides supplementary information regarding secur= e implementation >>> =C2=A0=C2=A0=C2=A0 and deployment of XMPP technologies. >>> >>> Here's the rationale: RFC 7525 is likely to be updated/replaced more >>> quickly than STUNbis. If STUNbis recommends a particular cipher suite= >>> that 7525bis stops recommending, in the absence of STUNter will STUN >>> implementations keep following STUNbis or will they upgrade to whatev= er >>> 7525bis recommends? I suggest it will be the former, which is not wha= t >>> we want. >> >> All right, makes sense.=C2=A0 I'll add something like this on my next >> round of reviews, most likely this Friday. >=20 > If you're going to add some wording about including TLS best current pr= actices, maybe you could re-use what we came up with during final RFC edi= tion of RFC 8143 : >=20 > 3.=C2=A0 Recommendations >=20 > =C2=A0=C2=A0 The best current practices documented in [BCP195] apply he= re. > =C2=A0=C2=A0 Therefore, NNTP implementations and deployments compliant = with this > =C2=A0=C2=A0 document are REQUIRED to comply with [BCP195] as well. >=20 > =C2=A0=C2=A0 Instead of repeating those recommendations here, this docu= ment mostly > =C2=A0=C2=A0 provides supplementary information regarding secure implem= entation > =C2=A0=C2=A0 and deployment of NNTP technologies. >=20 >=20 > Notably, the RFC Editor prefers referencing RFC 7525 as BCP 195 even th= ough there currently is only one RFC in this BCP series.=C2=A0 As other R= FCs may be added in BCP 195, and we want to follow all best practices tha= t apply, the reference should be the BCP series. >=20 Thanks, I used the BCP as reference, and changed the SHOULD to MUST. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --w0ECpTSTKe1lsKmqib92dfauL32s86Ucz-- --uveg8IQlS7aDvv6qn8mVKtqgZcmr5zzAw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrbpvgACgkQKcRFldZq fsRZtg//b9+86VTI0FqR9k1Kr6YqCmOjJTEqF7Y5RKA/fz+yA4wbeYDMaNYQKrxT 0jGjnLuGQ+SP+34B08pP0gNEroVRMLL3QrZF9k6W2qJNJNrnVIh1UZU7Vlqibmah g0d/SagWu6JrNQ/+jBzZLryEbX8PqZYmzM+F9Nmfi//YCk8nqWzNh0YRtRxTjnTz sdaAkKhyh6GIH0aOt5tQhKRwhcJ4gDQCTy1RO7P6f/kxDkr6BNO74C96lwAmfAst Tsg0wRwuhNRkPYCctDo1CAGZKvprGtCPJHwumIr58dtRUNO304BfrixRMBibZS6B 4F+xJchnTmLIAeOJUyDAfEl9FN5aRDqDYdtvLGW85B/IoFC/lvfy0kfVdUO5Efnq Ar/uENsyWLAqxI6tELv8SNYWtOF9DT5ZZZr3SJXGSjuqcYSZaX15fxDoZBui43u7 w5XZYNMPiL9DhSL1r8dS8Q2mNNFCppkoxxu+nk2UbcKLCud1QPdqGNOqekavxrZ3 WGambG9pbPGsI291zjC3Cf6X1dWWLofNUOXYveV71tY/iWxVdp6ZCs8cVUIiwn6c vphyd+Dj3bvhReRBd0onJR9LmNvolXKIoXXpBb91y6N0++2bLmeUHO1ZVG5FQ2i+ bViA7GrBupXUK1mSbL21QC3NHp3cqsA4ic15SbcMPtbngSLnHac= =E0jr -----END PGP SIGNATURE----- --uveg8IQlS7aDvv6qn8mVKtqgZcmr5zzAw-- From nobody Sat Apr 21 14:07:35 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 24C2212DA1C; Sat, 21 Apr 2018 14:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 MMuNw2MU9W9V; Sat, 21 Apr 2018 14:07:17 -0700 (PDT) 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 F2D9612D870; Sat, 21 Apr 2018 14:07:16 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7] (unknown [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7]) (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 66A64AE844; Sat, 21 Apr 2018 23:07:14 +0200 (CEST) To: Eric Rescorla , Peter Saint-Andre Cc: art@ietf.org, Marc Petit-Huguenin , draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: <5ec17f83-a2b0-8d5d-b17a-ac0977ede7b0@acm.org> Date: Sat, 21 Apr 2018 14:07:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="98hmvLnbeK34OLsFLLivKe9GO8PVcJ9qD" Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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: Sat, 21 Apr 2018 21:07:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --98hmvLnbeK34OLsFLLivKe9GO8PVcJ9qD Content-Type: multipart/mixed; boundary="7pBOOTQ0uqj41z8a1dMR9nVGu0qASzo4X"; protected-headers="v1" From: Marc Petit-Huguenin To: Eric Rescorla , Peter Saint-Andre Cc: art@ietf.org, Marc Petit-Huguenin , draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org Message-ID: <5ec17f83-a2b0-8d5d-b17a-ac0977ede7b0@acm.org> Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --7pBOOTQ0uqj41z8a1dMR9nVGu0qASzo4X Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/16/2018 08:12 PM, Eric Rescorla wrote: > On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre > wrote: >=20 >> Hi Marc, a few further comments inline. >> >> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >>> Hi Peter, >>> >>> Thanks for the review and sorry for the delay in responding, I was >> traveling for the last 4 weeks. >>> >>> See my responses inline. >>> >>> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>>> Reviewer: Peter Saint-Andre >>>> Review result: Ready with Nits >>>> >> >> >> >>>> The first paragaraph of Section 6.2.3 restates recommendations from = RFC >>>> 7525; why not simply reference that specification? >>> >>> The original text in RFC5389 said this: >>> >>> " When STUN is run by itself over TLS-over-TCP, the >>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >>> minimum. [...]" >>> >>> The new text is an attempt at updating it in the same spirit of givin= g >> minimal instructions and complementing them with a reference to RFC 75= 25 - >> which was the reason for the reference to RFC 7525 there. >>> >>> So I kept the text there, followed by the following paragraph, in >> addition of moving the original last paragraph in the Security >> Consideration section: >>> >>> " These recommendations are just a part of the the recommendations in= >>> [RFC7525] that implementations and deployments of a STUN usage usin= g >>> TLS or DTLS SHOULD follow." >> >> I would instead suggest that we do something like Section 2 of RFC 759= 0 >> for XMPP: >> >> The best current practices documented in the "Recommendations for >> Secure Use of TLS and DTLS" [RFC7525] are included here by referenc= e. >> Instead of repeating those recommendations here, this document most= ly >> provides supplementary information regarding secure implementation >> and deployment of XMPP technologies. >> >> Here's the rationale: RFC 7525 is likely to be updated/replaced more >> quickly than STUNbis. If STUNbis recommends a particular cipher suite >> that 7525bis stops recommending, in the absence of STUNter will STUN >> implementations keep following STUNbis or will they upgrade to whateve= r >> 7525bis recommends? I suggest it will be the former, which is not what= >> we want. >> >=20 > I forgot about this in my review, but you should also profile ciphers f= or > TLS 1.3. >=20 As suggested by Julien =C3=89lie, I now use BCP195 as reference. Would t= hat, and a future update of that BCP covering TLS 1.3 satisfy your commen= t? Thanks. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --7pBOOTQ0uqj41z8a1dMR9nVGu0qASzo4X-- --98hmvLnbeK34OLsFLLivKe9GO8PVcJ9qD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrbqAAACgkQKcRFldZq fsQ7ag/+PyCWVhHKj3h52iU2O79oyq95JdM0x2wGzZwnPeQRq1qdC5cBjLkUuxFr 66eDmK/IB63stz/AIVDaCjhx7CcGNVr9EW8btbEWHK3NesImERc62pV5tVF6lqja iWp5X219uGtslvEA6WXjn0zMGQFHu5cEcRzPQ/YTO5wdQKgsrO/wTn1WPkvhrfRk yBkUMfQ1duyISpm3yRO8WsAR6jU9dNxSUD9GaaN3GrFpRmiViipOp4Qh8g/9YqNX IXghOogy9Ym29zgvlnQMCzR1S5Ioh2iqfY1CSfR5KSIadWB/wjiqiTDywFg5yDL2 XIQUYSkALCqjuj5RtzLDPH5Fh34ucoJCSAafJoDZ1r8jSubWcC7emk/XZcYDOoal 0CAUGrvEoTltYnCW8Z0gLxQ0jSO/oIhFJ38RWB03Rz8SiQtM+nmuyZT0GORjoY2C ehAKuhxI3bUdM3TiTS8eZmATWTxB0mfDEBDVQc+1menKzhbuubBD6G8hMNgn3vQG te92Ab+9Rw4mWfbNtm6go05VvT8HeQDmJ00LjxDt7uv/QNgFRmH1LcmoSka8UNOe 52AiVy56rXnpV7OmwdNVNluKzcoidZRaT9xBuj+hstUqJZAexqMb53Sk8SfzvX/Q J5vaxF+MamqcquPB+nDFRoXI13dmJ4PAekTWwOP6Uf5pfqpobGE= =w+2b -----END PGP SIGNATURE----- --98hmvLnbeK34OLsFLLivKe9GO8PVcJ9qD-- From nobody Sat Apr 21 14:39: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 3365F12E8D7; Sat, 21 Apr 2018 14:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 m2_VXDnAAaUQ; Sat, 21 Apr 2018 14:39:33 -0700 (PDT) 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 0DD8012E8D4; Sat, 21 Apr 2018 14:39:33 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7] (unknown [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7]) (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 CE8D3AE844; Sat, 21 Apr 2018 23:39:29 +0200 (CEST) From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Message-ID: <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> Date: Sat, 21 Apr 2018 14:39:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s98ikjH5z0Zsqqs2k3YOVMmKQGsTBjEp5" Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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: Sat, 21 Apr 2018 21:39:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s98ikjH5z0Zsqqs2k3YOVMmKQGsTBjEp5 Content-Type: multipart/mixed; boundary="7ye6ecdV7BXtpLLNFuPOQAvHLJEquLJsZ"; protected-headers="v1" From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> In-Reply-To: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> --7ye6ecdV7BXtpLLNFuPOQAvHLJEquLJsZ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/17/2018 03:00 AM, Marc Petit-Huguenin wrote: > On 04/16/2018 05:22 PM, Peter Saint-Andre wrote: >> Hi Marc, a few further comments inline. >> >> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >>> Hi Peter, >>> >>> Thanks for the review and sorry for the delay in responding, I was tr= aveling for the last 4 weeks. >>> >>> See my responses inline. >>> >>> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>>> Reviewer: Peter Saint-Andre >>>> Review result: Ready with Nits >>>> >> >> >> >>>> The first paragaraph of Section 6.2.3 restates recommendations from = RFC >>>> 7525; why not simply reference that specification? >>> >>> The original text in RFC5389 said this: >>> >>> " When STUN is run by itself over TLS-over-TCP, the >>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >>> minimum. [...]" >>> >>> The new text is an attempt at updating it in the same spirit of givin= g minimal instructions and complementing them with a reference to RFC 752= 5 - which was the reason for the reference to RFC 7525 there. >>> >>> So I kept the text there, followed by the following paragraph, in add= ition of moving the original last paragraph in the Security Consideration= section: >>> >>> " These recommendations are just a part of the the recommendations in= >>> [RFC7525] that implementations and deployments of a STUN usage usin= g >>> TLS or DTLS SHOULD follow." >> >> I would instead suggest that we do something like Section 2 of RFC 759= 0 >> for XMPP: >> >> The best current practices documented in the "Recommendations for >> Secure Use of TLS and DTLS" [RFC7525] are included here by referenc= e. >> Instead of repeating those recommendations here, this document most= ly >> provides supplementary information regarding secure implementation >> and deployment of XMPP technologies. >> >> Here's the rationale: RFC 7525 is likely to be updated/replaced more >> quickly than STUNbis. If STUNbis recommends a particular cipher suite >> that 7525bis stops recommending, in the absence of STUNter will STUN >> implementations keep following STUNbis or will they upgrade to whateve= r >> 7525bis recommends? I suggest it will be the former, which is not what= >> we want. >=20 > All right, makes sense. I'll add something like this on my next round = of reviews, most likely this Friday. Done, see my other emails to Julien =C3=89lie and Ekr. >=20 >> >>>> Section 6.3.4 states: >>>> >>>> o If the error code is 500 through 599, the client MAY resend th= e >>>> request; clients that do so MUST limit the number of times the= y do >>>> this. >>>> >>>> It is reasonable to provide guidance as to the number of re-sends? >>> >>> Same issue here, that's a section that is unmodified from RFC 5389.=20 >> >> I understand. Now is our chance to fix it. :-) >> >>> As long as the client does not enter an endless loop of retransmissi= on, choosing different numbers of re-sends does not affect interoperabili= ty. >> >> Choosing different numbers is OK, but choosing an infinite number is >> not. Can we provide guidance as to how many is too many? 10? 50? 100? >=20 > Well, the text already states that an infinite number of of re-sends is= not compliant. Anyway, I am not sure how to determine a reasonable numb= er, but I'll try. I chose 4 as the maximum number of retransmissions. I based that on erro= r code 508 in TURN that defines a delay of 60 seconds between retransmiss= ions, so we now get a delay of 5 minutes before the client gives up in ca= se of insufficient capacity. The new text reads like this: "o If the error code is 500 through 599, the client MAY resend the request; clients that do so MUST limit the number of times they do this. Unless a specific error code specifies a different value, the number of retransmissions MUST be limited to 4." --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --7ye6ecdV7BXtpLLNFuPOQAvHLJEquLJsZ-- --s98ikjH5z0Zsqqs2k3YOVMmKQGsTBjEp5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrbr5AACgkQKcRFldZq fsRZGQ//d56hu0y7/tsLRJVANY6EEsyW3ZtI8+fpl6+ZAlg4GazKq6Lq1aLRc8FF 1JdJ/47IAEvByVVTQd2pb1NYf9hSE8QvInD9m9QeTpDbRKLpafdVuKpNOYtYnx8N fj+A0RGtwbzbm0RkUNAXBROT/aA/zcWEffT/zO010+chXXPoTqUJ3TEPczUk1BJ6 +p3m+S/kdg3u6xqtRPRsBwLK6i98ZwxfA4A/Yu2JZKjhfrEjlrw4xIJD0US7tvSb itpLEecbdQcyUz84mmTEsDOAwDEMECgaq3GEntsfxylCk211GsilC0GrKpBPIxi3 UpbIoPqKmb9Nf7lQVwsHnjUkOYB+/+SIj6mZJoXWu0AaIcGpvv9+EZweNiS6RJ3R BxBIg/BBoX4q61rUQUNuW0MrY/Jj0pV+n2iQBRgLO46LWUMTi8c0vQlSF/iFgV/8 HgLygsPP/u6Ce+wLMLvtvz/ZUPx3nFhtMwoGiqI05/GHG4UETx1H9GuurSXwCKRF GORQvb5UCx88OsOBq7+fb+YyE4qc5JkVu+rLxyPnIYYxnfZs6i59azvRAliHu7SZ tseRCH2bVBcuRdS0HoaUoGS+3mOgbqenO2pO31GojGMDvckjIC5zY5NE2bSH1TZc sr2eF6NCIzh3vX5qYh/fH4oD6xBnbS2tRs2/SuoGNs+/YooOBio= =cqIx -----END PGP SIGNATURE----- --s98ikjH5z0Zsqqs2k3YOVMmKQGsTBjEp5-- From nobody Sun Apr 22 11:39: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 380BF126CBF; Sun, 22 Apr 2018 11:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] 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 s_pZ_fXHLx7z; Sun, 22 Apr 2018 11:39:51 -0700 (PDT) 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 59E17120227; Sun, 22 Apr 2018 11:39:51 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7] (unknown [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7]) (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 8D29AAE844; Sun, 22 Apr 2018 20:39:47 +0200 (CEST) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tram@ietf.org References: <152390695800.19624.250040937113641569.idtracker@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: <5d8e3d9e-46bd-57ba-5c80-ff414ef2aca5@petit-huguenin.org> Date: Sun, 22 Apr 2018 11:39:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152390695800.19624.250040937113641569.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oFB9SoYimTa6EqYUex9JW4EzKuooVfeVd" Archived-At: Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram?= =?utf-8?q?-stunbis-16=3A_=28with_COMMENT=29?= 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, 22 Apr 2018 18:39:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oFB9SoYimTa6EqYUex9JW4EzKuooVfeVd Content-Type: multipart/mixed; boundary="UeJ5xpHytCrgCdBCt5doRi3L3j459DRga"; protected-headers="v1" From: Marc Petit-Huguenin To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tram@ietf.org Message-ID: <5d8e3d9e-46bd-57ba-5c80-ff414ef2aca5@petit-huguenin.org> Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Yes_on_draft-ietf-tram-stunbis?= =?UTF-8?Q?-16:_=28with_COMMENT=29?= References: <152390695800.19624.250040937113641569.idtracker@ietfa.amsl.com> In-Reply-To: <152390695800.19624.250040937113641569.idtracker@ietfa.amsl.com> --UeJ5xpHytCrgCdBCt5doRi3L3j459DRga Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Mirja, Thanks for the review, please see my responses inline. On 04/16/2018 12:29 PM, Mirja K=C3=BChlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-tram-stunbis-16: Yes >=20 [...] >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1) Maybe it would make sense to refer informationally to > draft-ietf-tram-stun-pmtud in section 6.1? Done, here's the new last paragraph: STUN provides no ability to handle the case where the request is under the MTU but the response would be larger than the MTU. It is not envisioned that this limitation will be an issue for STUN. The MTU limitation is a SHOULD, and not a MUST, to account for cases where STUN itself is being used to probe for MTU characteristics [RFC5780]. See also [I-D.ietf-tram-stun-pmtud] for a framework that use STUN to add Path MTU Discovery to protocols that lack one. Outside of this or similar applications, the MTU constraint MUST be followed. >=20 > 2) sec 6.2.2: This sentence seems to assume that only one request is s= ent per > TCP connection/each request sends out after a new SYN: "However, for a > request/response transaction, if the client has not > received a response by Ti seconds after it sent the SYN to establish= > the connection, it considers the transaction to have timed out.=E2=80= =9C > i don=E2=80=99t think that assumption would be correct. Maybe rephrase = this sentence=E2=80=A6? Right, the Ti timer should start when the unique request per transaction= is sent, not when the connection is established. Here's the new text: Reliability of STUN over TCP and TLS-over-TCP is handled by TCP itself, and there are no retransmissions at the STUN protocol level. However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the request message, it considers the transaction to have timed out. Ti SHOULD be configurable and SHOULD have a default of 39.5s. This value has been chosen to equalize the TCP and UDP timeouts for the default initial RTO. >=20 > 3) Also section 6.2.2: Should the client send keep-alives if a connecti= on is > hold open but currently not used? If not, I guess further recommendatio= n is > needed to address the case where a transmission fails because an existi= ng idle > TCP connection was used that doesn=E2=80=99t work anymore. In this case= , I'd say the > recommendation would be to send a RST and try to open a new TCP connect= ion. I feel that keep-alives recommendations are dependent on the specificity = of a STUN Usage, and should be left to the document specifying it. For e= xample in the TURN case there is probably enough frequent messages with t= he allocation and permission refresh to not mandate any kind of keep-aliv= e. OTOH for Basic STUN Usage (NAT discovery) a client will probably immed= iately close the TCP connection after retrieving the NAt transport addres= s. So I added TCP keep-alive to the list of what STUN Usages should discuss = (Section 13): o The keep-alive mechanism if STUN is run over TCP or TLS-over-TCP. I also added the following paragraph to section 6.2.2: The details of an eventual keep-alive mechanism are left to each STUN Usage. In any case if a transaction fails because an idle TCP connection doesn't work anymore the client SHOULD send a RST and try to open a new TCP connection. and I updated the Basic Usage to follow our own recommendations: [...] ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP and TCP. It MAY support STUN over TCP/TLS or ALTERNATE-SERVER mecha= nism for the same reason. It MUST support UDP and TCP. It MAY support STUN over TCP/TLS or STUN over UDP/DTLS; however, DTLS and TLS provide minimal security benefits in this basic mode of operation. It does not require a keep-alive mechanism as a TCP or TLS-over-TLS connection is closed after the end of the Binding transaction. It MAY utilize the FINGERPRINT mechanism but MUST NOT STUN over UDP/DTLS; however, DTLS and TLS provide minimal security benefits in this basic mode of operation. It does not require a keep-alive mechanism as a TCP or TLS-over-TLS connection is closed after the end of the Binding transaction. It MAY utilize the FINGERPRINT mechanism but MUST NOT [...] >=20 > 4) Should section 9.2 maybe provide further guidance on the lifetime of= the > (server-selected) nonce? I added this in the Security Considerations Section: Implementations and deployments of a STUN usage using the Long-Term Credential Mechanism (Section 9.2) MUST follow the recommendations in Section 5 of [RFC7616]. >=20 > 5) I'm sure, I just missed something but how does a server know if a fi= rst > request intends to use the Long-Term Credential Mechanism or not (see 9= =2E2.3.1. > and 9.2.4 I guess). Or is this pre-configured? Each STUN Usage defines what authentication mechanism it uses (see bullet= point 3 of section 13), so a server implementing a specific Usage knows = what to do with the first request. >=20 > 6) Section 6.3 says that this doc only specifies the procedures for the= new > spec in this document and subsequently says: "It checks [...] that the = magic > cookie field has the correct value..." However, given this spec obsolet= es > RFC5389, I think that section 11 should provide more guidance on how to= handle > "old" STUN messages. Or is the intention that an upgraded STUN server d= oes not > handle old requests anymore? If so that should be spelled out as well. STUNBis still contains the processing of "classic" STUN (aka RFC5389), wh= ich is what "old" STUN messages are (not RFC5389 messages). >=20 > 7) sec 14.5: "The value of the MESSAGE-INTEGRITY attribute is set to a = dummy > value." Should the dummy value be further specified? Also it looks like= there > was a compile problem on page 39. Is there text missing? Already responded to that point in Dale Worley review: "[...] the input is up to and including the attribute *preceding* the MES= SAGE-INTEGRITY attribute. The message attribute is only counted when cal= culating the length in the header [...] [...] the content of the MESSAGE-INTEGRITY is not used when computing the= hash, so the content itself is irrelevant." The text says: The text used as input to HMAC is the STUN message, up to and including the attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. =20 >=20 > 8) sec 17.6: Isn't "stuns 5349/upd" used for DTLS? If so, it should be= > registered! >=20 >=20 Answered by Adam Roach. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --UeJ5xpHytCrgCdBCt5doRi3L3j459DRga-- --oFB9SoYimTa6EqYUex9JW4EzKuooVfeVd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrc1uwACgkQKcRFldZq fsS3ChAAyp+TBVDgMBy3NpP85xAzoh31hXB+rT9YaJp5lIBuFZlD8BqUFiYrPo+L HYgeq2ccP8UoiBzIT8hk2Xd/ioEdgZgJwdQ80SfdeT4wlYRU0FoSiKhCQK6IuN0C m1/lAmqO7R5aURkBRtEwkrk0/WP4gWf4dfk1dtCjOBHCMcbDrte0qnr9CWva8SUX g/NQQ6TNBXAmNha7GpJd40IXQUlqKNL9liKXsdVkSWdeZOns8sLlm15d3nr63q6x cqpXR9Lfjr/+b6PwS23ZTc0cYaQYuA5ZWSp2sIRDrBHfM3hXWHP3oaSDOyAuyH9g F+JLXBmUOizhHEF8R05nrl8iLj3wl878zL5OxeuSOnQf5f/gMQwvkqu9LcA4H+mG Oqs43mcd9K3KxYbnu0eCHmpqdNR9fp4NgLC6eZS6jlMXWF8H3KxC1a+D9hwdWQ1z xGruXKUh+jBzKbMph36y4DzW78wjfqDUQByCiuANAH/jbg47A1HN8fMjU0/1pL5+ Q+ENkmRONcpvaFuFODYNrgMPP47NpGGwdC4kINqvDWe4M5V3yn9t4GlUvb9p/El4 ikR2iBp8BZ4Z18G8QtqNA4nXSAy9zj/Qn5RF/wKolDeKUhXhhog0hKwGl5LDAaX/ FNJFBMvCHZhbhEG/sO6Jjg80Xn7oJKXUoiNShetM1mjCnBZhx6w= =Je2Y -----END PGP SIGNATURE----- --oFB9SoYimTa6EqYUex9JW4EzKuooVfeVd-- From nobody Sun Apr 22 14:02: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 0B1431200F1; Sun, 22 Apr 2018 14:02:46 -0700 (PDT) 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 ioXa7uh7bG0d; Sun, 22 Apr 2018 14:02:42 -0700 (PDT) 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 47444126D85; Sun, 22 Apr 2018 14:02:42 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:407e:9f96:b05f:7bbb] (unknown [IPv6:2601:648:8301:730f:407e:9f96:b05f:7bbb]) (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 0B188AE844; Sun, 22 Apr 2018 23:02:38 +0200 (CEST) To: Eric Rescorla , The IESG Cc: tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: Date: Sun, 22 Apr 2018 14:02:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5OLvpxuAyIWJl4oB9AupIasxFR4xtVdce" Archived-At: Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) 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, 22 Apr 2018 21:02:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5OLvpxuAyIWJl4oB9AupIasxFR4xtVdce Content-Type: multipart/mixed; boundary="cKT7M4TdFPTMNI3KT2NEYB1VREti8KD8t"; protected-headers="v1" From: Marc Petit-Huguenin To: Eric Rescorla , The IESG Cc: tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org Message-ID: Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> In-Reply-To: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> --cKT7M4TdFPTMNI3KT2NEYB1VREti8KD8t Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Eric, Thanks for the review, please see my responses inline. On 04/16/2018 12:57 PM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-tram-stunbis-16: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D5132 >=20 >=20 > Can you please indicate how you addressed the points Matt Miller > raised in his secdir review about the use of MD5. =46rom my response on 2018-03-11: > * The description for 17.5.1. "MD5" list the key size as 20 bytes, but = the > hash length of MD5 is 16 bytes (128 bits). I think this is merely a ty= po, > since the purpose appears to be for backwards compatibility with existi= ng > systems. Fixed. > > * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credential)= > and Section appear to define the same functional algorithm, but with su= btle > syntax differences. As far as I can tell, they are actually the same > algorithm; would it not be acceptable to have Section 9.2.2 point to > Section 17.5.1.1 for the algorithm description? > > This is going into the IANA registry so I left things there. I fixed the= discrepancy with section 9.2.2. I also fixed the definition of the key for SHA-256, which must use Opaque= String for the realm. >=20 >=20 >=20 > DETAIL >> by the agent sending the indication. It primarily serves to >> correlate requests with responses, though it also plays a small r= ole >> in helping to prevent certain types of attacks. The server also = uses >> the transaction ID as a key to identify each transaction uniquely= >> across all clients. As such, the transaction ID MUST be uniforml= y >> and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be= >=20 > I didn't realize this was a SHOULD. ICE depends on it as a security > condition, so it probably needs to be a MUST. Done. >=20 >=20 >> For a request or indication message, the agent MUST include the >> USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attribu= tes >> in the message unless the agent knows from an external indication= >> which message integrity algorithm is supported by both agents. I= n >> this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MU= ST >> be included in addition to USERNAME. The HMAC for the MESSAGE- >=20 > This text appears to conflict with S 7.3 of 5245-bis, which says: [text missing] Hmm, no, RFC245bis is still referencing RFC5389, so the procedure for stu= nbis does not apply. >=20 >=20 >> STUN Security Feature it is understood that the corresponding STU= N >> Security Feature bit in the "nonce cookie" is set to 1. >> >> For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS >> security feature, it is implied that the "Password algorithms" bi= t, >> as defined in Section 17.1, is set to 1 in the "nonce cookie". >=20 > I'm not sure I understand the bid down attack here or the proposed > defense. Can you please walk through what the assumed attacker > capabilities are, what the client and server capabilities are, how the > bid down attack works, and how this protects against it? The plan is to add an annex to the document explaining that. I'll finish= to process the other reviews from the IESG and then come back to that. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >> >> In keeping with its tool nature, this specification defines an >> extensible packet format, defines operation over several transpor= t >> protocols, and provides for two forms of authentication. >> >> STUN is intended to be used in context of one or more NAT travers= al >=20 > Nit: "in the context" Applied. >=20 >=20 >> of [RFC0791]. Unless otherwise noted, numeric constants are in >> decimal (base 10). >> >> All STUN messages comprise a 20-byte header followed by zero or m= ore >> Attributes. The STUN header contains a STUN message type, magic >> cookie, transaction ID, and message length. >=20 > You might want to list these in order. Done. >=20 >=20 >> The STUN usage must specify which transport protocol is used, and= how >> the agent determines the IP address and port of the recipient. >> Section 8 describes a DNS-based method of determining the IP addr= ess >> and port of a server that a usage may elect to use. STUN may be = used >> with anycast addresses, but only with UDP and in usages where >> authentication is not used. >=20 > Why this restriction? You should be able to use anycast with long-term > AUTH for (say) TURN. https://www.ietf.org/mail-archive/web/behave/current/msg03582.html I think that the decision of permitting Anycast should be left to each ST= UN Usage. Basic STUN Usage does not use authentication and use only a on= e round trip for the Binding transaction, so Unicast can be used. OTOH, TURN and ICE should probably say something about that, so I added a= new bullet point in Section 13: o If Anycast addresses can be used for the server in case TCP or TLS-over-TCP, or authentication are used. >=20 >=20 >> First, the initial value for RTO SHOULD be greater than 500 ms. = The >> exception cases for this "SHOULD" are when other mechanisms are u= sed >> to derive congestion thresholds (such as the ones defined in ICE = for >> fixed rate streams), or when STUN is used in non-Internet >> environments with known network capacities. In fixed-line access= >> links, a value of 500 ms is RECOMMENDED. Second, the value of RT= O >=20 > I note that above you say "greater than 500 ms" but here you say "500 > ms". Perhaps you mean greater than equal. Fixed. >=20 >=20 >> transaction over UDP or DTLS-over-UDP is also considered failed i= f >> there has been a hard ICMP error [RFC1122]. For example, assumin= g an >> RTO of 500ms, requests would be sent at times 0 ms, 500 ms, 1500 = ms, >> 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not >> received a response after 39500 ms, the client will consider the >> transaction to have timed out. >=20 > I note that these recommendations now seem crazily long. I assume the > WG had consensus on this, but I wanted to note it. Not just the WG, also the IESG that approved RFC 5389 too as, but for the= addition of "or DTLS-over-UDP", this is the same text than in RFC 5389. >=20 >=20 >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites MUST be >> implemented and other cipher suites MAY be implemented. Perfect >> Forward Secrecy (PFS) cipher suites MUST be preferred over non-PF= S >> cipher suites. Cipher suites with known weaknesses, such as thos= e >> based on (single) DES and RC4, MUST NOT be used. Implementations= >> MUST disable TLS-level compression. >=20 > Would it be better to just cite to RFC 7525 here? Already modified following Peter Saint-Andre review. >=20 >=20 >> >> o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute t= he >> value for the message integrity as described in Section 14.6, >> using the password associated with the username. If the MESSA= GE- >> INTEGRITY-SHA256 attribute is not present, and using the same >> password, compute the value for the message integrity as descr= ibed >=20 > This text is a bit unclear. I think you mean "If the MESSAGE- > INTEGRITY-SHA256 attribute is not present, then use the same password > to compute the..." Applied. >=20 >=20 >> a nonce. The nonce provides the replay protection. It is a cook= ie, >> selected by the server, and encoded in such a way as to indicate = a >> duration of validity or client identity from which it is valid. = The >> client retries the request, this time including its username and = the >> realm, and echoing the nonce provided by the server. The client = also >> includes a message-integrity, which provides an HMAC over the ent= ire >=20 > Nit: "a message integrity attribute".=20 Applied. > Also, how do I know which one to > use? This is explained later in Section 9.2.3.2.: The choice between the two attributes depends on the attribute received in the response to the first request. >=20 >=20 >> ALTERNATE-SERVER where authentication of the response is not poss= ible >> or practical. If the transaction uses TLS or DTLS and if the >> transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attrib= ute >> and if the server wants to redirect to a server that uses a diffe= rent >> certificate, then it MUST include an ALTERNATE-DOMAIN attribute >> containing the subjectAltName of that certificate. >=20 > 1. Why is MESSAGE-INTEGRITY-SHA256 relevant here? ALTERNATE-DOMAIN exists only since stunbis, so the MESSAGE-INTEGRITY-SHA2= 56 acts as a flag indicating that 1) the transaction is authenticated and= 2) that the client understand that new attribute. >=20 >=20 >> o What authentication and message-integrity mechanisms are used.= >> >> o The considerations around manual vs. automatic key derivation = for >> the integrity mechanism, as discussed in [RFC4107]. >> >> o What mechanisms are used to distinguish STUN messages from oth= er >=20 > Why is this required? It seems like that's a generic STUN feature. That text is identical to the text in RFC 5389. RFC 5764/7983 is one suc= h mechanism, but there is nothing that prevent another protocol stack to = use a different mechanism (inference, shim, etc...) >=20 >=20 >> to the end of the MESSAGE-INTEGRITY-SHA256 attribute prior to >> calculating the HMAC over the STUN message, up to and including t= he >> attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. Such= >> adjustment is necessary when attributes, such as FINGERPRINT, app= ear >> after MESSAGE-INTEGRITY-SHA256. See also Appendix B.1 for exampl= es >> of such calculations. >=20 > So if M-I-SHA256 and M-I appear together, one includes the other but > not vice versa? Yes, it is based on the text in RFC 5389 that says that everything after = MESSAGE-INTEGRITY but FINGERPRINT must be ignored. An RFC 5389 just igno= re MESSAGE-INTEGRITY-SHA256. Conversely stunbis says that everything after MESSAGE-INTEGRITY-SHA256 bu= t FINGERPRINT must be ignored, keeping the possibility in stun-ter to add= yet another MESSAGE-INTEGRITY attribute after that. >=20 >=20 >> transport protocol uses TLS or DTLS. >> >> The value of ALTERNATE-DOMAIN is variable length. It MUST be a U= TF-8 >> [RFC3629] encoded sequence of less than 128 characters (which can= be >> as long as 509 bytes when encoding them and as long as 763 bytes = when >> decoding them). >=20 > Is it an A-label or a U-label? I do not know. What would you suggest? >=20 >=20 >> that is not readily subject to offline dictionary attacks. >> Protection of the channel itself, using TLS or DTLS, mitigates th= ese >> attacks. >> >> STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256= , >> which is subject to bid down attacks by an on-path attacker. >=20 > By an on-path attacker who can forge HMAC-SHA1 in real-time? That's a > pretty serious adversary, so you should clarify here >=20 New text: STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, which is subject to bid down attacks by an on-path attacker that would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving only the MESSAGE-INTEGRITY attribute and exploiting a potential vulnerability. Protection of the channel itself, using TLS or DTLS, mitigates these attacks. Timely removal of the support of MESSAGE-INTEGRITY in a future version of STUN is necessary. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --cKT7M4TdFPTMNI3KT2NEYB1VREti8KD8t-- --5OLvpxuAyIWJl4oB9AupIasxFR4xtVdce Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrc+GgACgkQKcRFldZq fsSOZRAAougNFdr+v8NeXcQ0EEHx/i7GceM+8Y9UXaE8mIiKjS6BH5DlOTRPEC/n /3AgNPb3qGk9lpB+9hxaqO2qoS2lAl4wfr1VSC3P3D1WHBv2wvAN1KAknS6tBtgh r7qFJkdq8eCsu+AvFUcnA9iM0qdiGh7d0sD4mM7qU8QumcXRtc4hwx6qG6phzVOT 2PS/erCGRSJUV0MGKFU+3pH8/Q4H2hxbtg+ZKSeWBsrTbUyeK5W1oKhsHbVP2C3R AeEUY67FZJoAAIkNPx24P6Bd/VyyTEWp/ZD5vFxzt5meY6sOyREXdjt8h5c9Zi0Y HVYPXMxr4UYHbsAXiY7ukeXY3lFS6gYucwyPlO7lVdUOK5xhbzuxJg6DoD/qGkpQ o8ITJOTC+LfofuHymXfqhdHAHj4r2Ryu43qZcbp3+M0otMhaEGOdR50id5UU3+zA HGeYOKYnss/iRBYW7zLXmQR6nNHtToMM+ZQ/r7azAdWDK1628HU7ld/7J0qWM7Wt AyQLcFSc7nAPSrtQHxCyiF6DZPKbBaue9deD4LL0k7BkjzLzEjAWN0linJ8CH7CY jGm+K6IowAH25DSjzr8gOH+wd1sMaiNvGJpLp3QMWxuakEY8JnkcEQuFcHEG3wr2 WflOlMBkTeVOhnqn70iCPthx1x5eAR8bgLLztnGQfwAh546TIAw= =FlHc -----END PGP SIGNATURE----- --5OLvpxuAyIWJl4oB9AupIasxFR4xtVdce-- From nobody Sun Apr 22 14:31: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 0CBF8124B18; Sun, 22 Apr 2018 14:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] 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 bMjbPgSW_HFJ; Sun, 22 Apr 2018 14:31:50 -0700 (PDT) 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 AE9491200F1; Sun, 22 Apr 2018 14:31:50 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:407e:9f96:b05f:7bbb] (unknown [IPv6:2601:648:8301:730f:407e:9f96:b05f:7bbb]) (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 303D0AE844; Sun, 22 Apr 2018 23:31:48 +0200 (CEST) To: Ben Campbell , The IESG Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tram@ietf.org References: <152393106321.26096.12146305230255636553.idtracker@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: <4689aba3-e1a4-b519-079c-2361c422724e@petit-huguenin.org> Date: Sun, 22 Apr 2018 14:31:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152393106321.26096.12146305230255636553.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZZqgCpWscOqcmkgxNWBYs253DZbnbC3uR" Archived-At: Subject: Re: [tram] Ben Campbell's No Objection on draft-ietf-tram-stunbis-16: (with COMMENT) 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, 22 Apr 2018 21:31:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZZqgCpWscOqcmkgxNWBYs253DZbnbC3uR Content-Type: multipart/mixed; boundary="kYt4snKttfHtbPi3SjeBKEJ2HTR10Aoie"; protected-headers="v1" From: Marc Petit-Huguenin To: Ben Campbell , The IESG Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tram@ietf.org Message-ID: <4689aba3-e1a4-b519-079c-2361c422724e@petit-huguenin.org> Subject: Re: Ben Campbell's No Objection on draft-ietf-tram-stunbis-16: (with COMMENT) References: <152393106321.26096.12146305230255636553.idtracker@ietfa.amsl.com> In-Reply-To: <152393106321.26096.12146305230255636553.idtracker@ietfa.amsl.com> --kYt4snKttfHtbPi3SjeBKEJ2HTR10Aoie Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Ben, Thanks for the review, please see my responses inline. On 04/16/2018 07:11 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-tram-stunbis-16: No Objection >=20 [...] >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Hi, thanks for this work. For the record, I have mainly reviewed the di= ff. >=20 > General: I think Peter's ART-ART review has some points worth addressin= g. I think I addressed all of Peter's comments. >=20 > =C2=A71, last paragraph: This seems out of place.=20 > Also, I wonder if it should be > stated more strongly, perhaps with a SHOULD or even MUST. Already fixed following a previous review. >=20 > =C2=A73: RFC 8174 offers it's own recommended boilerplate; is there a r= eason not to > use it? Already fixed following a previous review. >=20 > =C2=A76.2.1, third paragraph: " The value SHOULD be considered stale an= d discarded > after > 10 minutes without any transactions to the same server. " > This is a bit ambiguous. I think it means the value is stale if no tran= sactions > have occurred in the last 10 minutes, But I think it could be read to s= ay that > there should be no transactions to the same server once one considers t= he value > as stale. The new text reads: The value SHOULD be considered stale and discarded if no transactions have occurred to the same server in the last 10 minutes. >=20 > =C2=A79.1.4: Does it make sense to signal that "an attack took place" r= ather than > signaling "integrity protection was violated" and let the human operato= rs > decide if that implies an attack? Applied. >=20 > =C2=A714.3: "A compliant implementation MUST > be able to parse UTF-8 encoded sequence of less than 763." >=20 > 763 whats? Already fixed following a previous review. >=20 > =C2=A715.3, 2nd bullet: I'm not sure I understand what is meant by "get= an updated > external mechanism" >=20 >=20 New text: o STUN Client and Server using the Short Term Credential Mechanism will need to update the external mechanism that they use to signal what message-integrity attributes are in use. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --kYt4snKttfHtbPi3SjeBKEJ2HTR10Aoie-- --ZZqgCpWscOqcmkgxNWBYs253DZbnbC3uR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrc/0IACgkQKcRFldZq fsT+kxAAlRhBsMupTpLgH8U5mLhUPyoe9J7DOb3H0e/XRjqYoZyc71S9Xlb8ZfwN 0u1HtSyRySybJ4VBhX/WdIFuhbwuf5a86M4knW/4CBSTMyX6tplxGSepru0A65KU fwCXYMd4aF4vC6rXC0tdLO2QUCVQk9UVNk+lFTOcHLZkxsk0YQAUVeJY9u6zqU66 oLuG27/H2yDQ/LbtzE7vZyjgm71PLG8/msxEU2H2CEzzcm2bl+HWxPSwwPy2MT7r nxmQ/oEZyM6n4WIqWz1aHNtmIBs1tDb6wBTl4zdaVCm+NiGkpVdTjY9gf/U5kRxN Dcz6yUKeZUebGmVtL+1hUdwnoTaLgp0R9OycDiETP5lwnXQ7PgcDswY+bGc5DP1B O3RlT5UDeo1lPjAKwoL2S5ciGGsconEojoZKkY7COMaGJylqc/xZeZvu7xZB+CJf AuzSALae3NPiguI4ltS5e9HtPgfkvSM7/hwWM+vabRHkbMCaQ6mhlbnGxMCYEYj5 RL/8bGwgvAb/FNv5HcJ15o1TZdQVsf9iFKSA+IgRET6jpmacwFbNWpDTveJPCDbv yQbisGJqbLPmznTr1zdKUxnHVf3AtgRDqMsz8+sqYHmaRNhvzrDMzzmbq8ujaJu7 CHX6uVjoSpZ/SC1EVis3pKxQr/FQrCGPEOG/5jPy6c8ksZXxG4E= =CTdC -----END PGP SIGNATURE----- --ZZqgCpWscOqcmkgxNWBYs253DZbnbC3uR-- From nobody Sun Apr 22 17:23:07 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 2E6D8126D73 for ; Sun, 22 Apr 2018 17:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 pdVM7-n2tq30 for ; Sun, 22 Apr 2018 17:22:59 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 83E3F1241F3 for ; Sun, 22 Apr 2018 17:22:56 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id w4-v6so15334209ote.12 for ; Sun, 22 Apr 2018 17:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GTTFVyVATBms960Y3SuwqD2Z85Qr3ZFVM0zQU/NXeYk=; b=TNQqjbGSvowZS6fEhb1pfCdcPFuiQZ7KOJB6SZiJFciidluRXGRW5s8l0HYKDXszs3 j1v7sSX6nPODCLdsquB7mWiQvFClOhgJkilfmYg9gxeF7513YIUHqJg6mjTaI+Oyzsnl D4u2bICLQpDwq2tgbbPv7wIJAONdZUyPQQZr1h9S8us5K759mDb9/CQdx4pZllHxNlkj f6vJBjKzTETioZ2ESsLBALLGEQdFtJ6M57LlxkWfWIB+xOrpY9aOYlal8aeKimcSZMYt T20EY7cnYfmapykrJuS9wcgupjQAffMUin4bUL6mQlo1PcXxXSo9Thidzp8nWtvYK+zh CqFQ== 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=GTTFVyVATBms960Y3SuwqD2Z85Qr3ZFVM0zQU/NXeYk=; b=aped+AQ44bd6eXCOLkuw3XH87R2MQo0vR/W9a9AntA+MmKadq9nQaym4U2qks/Wxec 3+bPpPHP3ULsQZH0t9PF9VNFZaUyxoIIhv7JEjJOow+RzvWuiqscP1PboEbhHmoeEkYG P/pXVa3mYUoSl99dGYePeaBta/twDcGkASu/vhyrEPexlYaooaQMkBUFkOzZB+of6yQU rfEPgbwQaCcQABuoaFEPtXzr2+sd6ozdg90Uy49HDVqe2gRLKOdW/xTZJ5W7neBvi8Dm 0osXQXMPHVo+1UzjZsudUP4SHSE+h47+/9v8D7XJ5C31l02Cykx318osbDJxaf/nl6E8 gQLw== X-Gm-Message-State: ALQs6tDRg0g2OppcPm5ytteiiMqXiCsmdeCxCDbJ36qzgM7XnhohcQ26 0jxvzJB83/ZCTmse2bNQ+NYe6Tkbcx2FAyOtnB95Tg== X-Google-Smtp-Source: AIpwx498aUQW3aCbwSGX92vocN2jToKgmK6kHb4HxZy9Lt0nAruphbIrTifUGSaoQnlDGH0khOCE0XILHcQr8MBbnQ4= X-Received: by 2002:a9d:3b03:: with SMTP id z3-v6mr12036015otb.392.1524442975869; Sun, 22 Apr 2018 17:22:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Sun, 22 Apr 2018 17:22:15 -0700 (PDT) In-Reply-To: References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Sun, 22 Apr 2018 17:22:15 -0700 Message-ID: To: Marc Petit-Huguenin Cc: The IESG , tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo Camarillo , draft-ietf-tram-stunbis@ietf.org, tram@ietf.org Content-Type: multipart/alternative; boundary="0000000000000eb4b1056a790af1" Archived-At: Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) 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, 23 Apr 2018 00:23:02 -0000 --0000000000000eb4b1056a790af1 Content-Type: text/plain; charset="UTF-8" On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin wrote: > > >> For a request or indication message, the agent MUST include the > >> USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY > attributes > >> in the message unless the agent knows from an external indication > >> which message integrity algorithm is supported by both agents. In > >> this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST > >> be included in addition to USERNAME. The HMAC for the MESSAGE- > > > > This text appears to conflict with S 7.3 of 5245-bis, which says: > > [text missing] > > Hmm, no, RFC245bis is still referencing RFC5389, so the procedure for > stunbis does not apply. > I hear what you're saying, but publishing two documents at the same time which make contrary recommendations about the same basic protocol is un-good. >> The STUN usage must specify which transport protocol is used, and > how > >> the agent determines the IP address and port of the recipient. > >> Section 8 describes a DNS-based method of determining the IP > address > >> and port of a server that a usage may elect to use. STUN may be > used > >> with anycast addresses, but only with UDP and in usages where > >> authentication is not used. > > > > Why this restriction? You should be able to use anycast with long-term > > AUTH for (say) TURN. > > https://www.ietf.org/mail-archive/web/behave/current/msg03582.html > > I think that the decision of permitting Anycast should be left to each > STUN Usage. Basic STUN Usage does not use authentication and use only a > one round trip for the Binding transaction, so Unicast can be used. > > OTOH, TURN and ICE should probably say something about that, so I added a > new bullet point in Section 13: > > o If Anycast addresses can be used for the server in case TCP or > TLS-over-TCP, or authentication are used. > Are you leaving this text in? That seems very confusing. > >> transaction over UDP or DTLS-over-UDP is also considered failed if > >> there has been a hard ICMP error [RFC1122]. For example, assuming > an > >> RTO of 500ms, requests would be sent at times 0 ms, 500 ms, 1500 > ms, > >> 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not > >> received a response after 39500 ms, the client will consider the > >> transaction to have timed out. > > > > I note that these recommendations now seem crazily long. I assume the > > WG had consensus on this, but I wanted to note it. > > Not just the WG, also the IESG that approved RFC 5389 too as, but for the > addition of "or DTLS-over-UDP", this is the same text than in RFC 5389. > Yes, I know. My point is that while they might have bee sensible when 5389 was published they *now* seem crazily long. Did the WG explicitly decide not to update them? > >> ALTERNATE-SERVER where authentication of the response is not > possible > >> or practical. If the transaction uses TLS or DTLS and if the > >> transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 > attribute > >> and if the server wants to redirect to a server that uses a > different > >> certificate, then it MUST include an ALTERNATE-DOMAIN attribute > >> containing the subjectAltName of that certificate. > > > > 1. Why is MESSAGE-INTEGRITY-SHA256 relevant here? > > ALTERNATE-DOMAIN exists only since stunbis, so the > MESSAGE-INTEGRITY-SHA256 acts as a flag indicating that 1) the transaction > is authenticated and 2) that the client understand that new attribute. > This would be good to explain. > >> o What authentication and message-integrity mechanisms are used. > >> > >> o The considerations around manual vs. automatic key derivation > for > >> the integrity mechanism, as discussed in [RFC4107]. > >> > >> o What mechanisms are used to distinguish STUN messages from other > > > > Why is this required? It seems like that's a generic STUN feature. > > That text is identical to the text in RFC 5389. RFC 5764/7983 is one such > mechanism, but there is nothing that prevent another protocol stack to use > a different mechanism (inference, shim, etc...) > But ultimately no matter what the other protocol provides for demux, STUN has its own demux. >> transport protocol uses TLS or DTLS. > >> > >> The value of ALTERNATE-DOMAIN is variable length. It MUST be a > UTF-8 > >> [RFC3629] encoded sequence of less than 128 characters (which can > be > >> as long as 509 bytes when encoding them and as long as 763 bytes > when > >> decoding them). > > > > Is it an A-label or a U-label? > > I do not know. What would you suggest? > I believe Alexey raised this separately, so I would refer to his comments. > > > > >> that is not readily subject to offline dictionary attacks. > >> Protection of the channel itself, using TLS or DTLS, mitigates > these > >> attacks. > >> > >> STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, > >> which is subject to bid down attacks by an on-path attacker. > > > > By an on-path attacker who can forge HMAC-SHA1 in real-time? That's a > > pretty serious adversary, so you should clarify here > > > > New text: > > STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, > which is subject to bid down attacks by an on-path attacker that > would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving only the > MESSAGE-INTEGRITY attribute and exploiting a potential vulnerability. > Protection of the channel itself, using TLS or DTLS, mitigates these > attacks. Timely removal of the support of MESSAGE-INTEGRITY in a > future version of STUN is necessary. > I still don't understand the capabilities you seem to believe the attacker has. Can you describe the exact attack. --0000000000000eb4b1056a790af1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin = <petithug@acm.org<= /a>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 For a request or indication message, the agent= MUST include the
>>=C2=A0 =C2=A0 =C2=A0 USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAG= E-INTEGRITY attributes
>>=C2=A0 =C2=A0 =C2=A0 in the message unless the agent knows from an = external indication
>>=C2=A0 =C2=A0 =C2=A0 which message integrity algorithm is supported= by both agents.=C2=A0 In
>>=C2=A0 =C2=A0 =C2=A0 this case either MESSAGE-INTEGRITY or MESSAGE-= INTEGRITY-SHA256 MUST
>>=C2=A0 =C2=A0 =C2=A0 be included in addition to USERNAME.=C2=A0 The= HMAC for the MESSAGE-
>
> This text appears to conflict with S 7.3 of 5245-bis, which says:

[text missing]

Hmm, no, RFC245bis is still referencing RFC5389, so the procedure for stunb= is does not apply.

I hear what you'= re saying, but publishing two documents at the same= time which
make contrary recommendations about the same basic pr= otocol is un-good.

<= span class=3D"">
>>=C2=A0 =C2=A0 =C2=A0 The STUN usage must specify which transport pr= otocol is used, and how
>>=C2=A0 =C2=A0 =C2=A0 the agent determines the IP address and port o= f the recipient.
>>=C2=A0 =C2=A0 =C2=A0 Section 8 describes a DNS-based method of dete= rmining the IP address
>>=C2=A0 =C2=A0 =C2=A0 and port of a server that a usage may elect to= use.=C2=A0 STUN may be used
>>=C2=A0 =C2=A0 =C2=A0 with anycast addresses, but only with UDP and = in usages where
>>=C2=A0 =C2=A0 =C2=A0 authentication is not used.
>
> Why this restriction? You should be able to use anycast with long-term=
> AUTH for (say) TURN.

https://www.ietf.org/mail-<= wbr>archive/web/behave/current/msg03582.html

I think that the decision of permitting Anycast should be left to each STUN= Usage.=C2=A0 Basic STUN Usage does not use authentication and use only a o= ne round trip for the Binding transaction, so Unicast can be used.

OTOH, TURN and ICE should probably say something about that, so I added a n= ew bullet point in Section 13:

=C2=A0 =C2=A0o=C2=A0 If Anycast addresses can be used for the server in cas= e TCP or
=C2=A0 =C2=A0 =C2=A0 TLS-over-TCP, or authentication are used.

Are you leaving this text in? That seems very confu= sing.


>>=C2=A0 =C2=A0 =C2=A0 transaction over UDP or DTLS-over-UDP is also = considered failed if
>>=C2=A0 =C2=A0 =C2=A0 there has been a hard ICMP error [RFC1122].=C2= =A0 For example, assuming an
>>=C2=A0 =C2=A0 =C2=A0 RTO of 500ms, requests would be sent at times = 0 ms, 500 ms, 1500 ms,
>>=C2=A0 =C2=A0 =C2=A0 3500 ms, 7500 ms, 15500 ms, and 31500 ms.=C2= =A0 If the client has not
>>=C2=A0 =C2=A0 =C2=A0 received a response after 39500 ms, the client= will consider the
>>=C2=A0 =C2=A0 =C2=A0 transaction to have timed out.
>
> I note that these recommendations now seem crazily long. I assume the<= br> > WG had consensus on this, but I wanted to note it.

Not just the WG, also the IESG that approved RFC 5389 too as, but fo= r the addition of "or DTLS-over-UDP", this is the same text than = in RFC 5389.

Ye= s, I know. My point is that while they might have bee sensible when
5389 was published they *now* seem crazily long. Did the WG explicitly
decide not to update them?


=C2=A0
>>=C2=A0 =C2=A0 =C2=A0 ALTERNATE-SERVER where authentication of the r= esponse is not possible
>>=C2=A0 =C2=A0 =C2=A0 or practical.=C2=A0 If the transaction uses TL= S or DTLS and if the
>>=C2=A0 =C2=A0 =C2=A0 transaction is authenticated by a MESSAGE-INTE= GRITY-SHA256 attribute
>>=C2=A0 =C2=A0 =C2=A0 and if the server wants to redirect to a serve= r that uses a different
>>=C2=A0 =C2=A0 =C2=A0 certificate, then it MUST include an ALTERNATE= -DOMAIN attribute
>>=C2=A0 =C2=A0 =C2=A0 containing the subjectAltName of that certific= ate.
>
> 1. Why is MESSAGE-INTEGRITY-SHA256 relevant here?

ALTERNATE-DOMAIN exists only since stunbis, so the MESSAGE-INTEGRITY= -SHA256 acts as a flag indicating that 1) the transaction is authenticated = and 2) that the client understand that new attribute.
=
This would be good to explain.


>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 What authentication and message-integr= ity mechanisms are used.
>>
>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 The considerations around manual vs. a= utomatic key derivation for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the integrity mechanism, as discu= ssed in [RFC4107].
>>
>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 What mechanisms are used to distinguis= h STUN messages from other
>
> Why is this required? It seems like that's a generic STUN feature.=

That text is identical to the text in RFC 5389.=C2=A0 RFC 5764/7983 = is one such mechanism, but there is nothing that prevent another protocol s= tack to use a different mechanism (inference, shim, etc...)

But ultimately no matter what the other protocol provi= des for demux, STUN has its
own demux.


>>=C2=A0 =C2=A0 =C2=A0 transport protocol uses TLS or DTLS.
>>
>>=C2=A0 =C2=A0 =C2=A0 The value of ALTERNATE-DOMAIN is variable leng= th.=C2=A0 It MUST be a UTF-8
>>=C2=A0 =C2=A0 =C2=A0 [RFC3629] encoded sequence of less than 128 ch= aracters (which can be
>>=C2=A0 =C2=A0 =C2=A0 as long as 509 bytes when encoding them and as= long as 763 bytes when
>>=C2=A0 =C2=A0 =C2=A0 decoding them).
>
> Is it an A-label or a U-label?

I do not know.=C2=A0 What would you suggest?

I believe Alexey raised this separatel= y, so I would refer to his comments.

>
>
>>=C2=A0 =C2=A0 =C2=A0 that is not readily subject to offline diction= ary attacks.
>>=C2=A0 =C2=A0 =C2=A0 Protection of the channel itself, using TLS or= DTLS, mitigates these
>>=C2=A0 =C2=A0 =C2=A0 attacks.
>>
>>=C2=A0 =C2=A0 =C2=A0 STUN supports both MESSAGE-INTEGRITY and MESSA= GE-INTEGRITY-SHA256,
>>=C2=A0 =C2=A0 =C2=A0 which is subject to bid down attacks by an on-= path attacker.
>
> By an on-path attacker who can forge HMAC-SHA1 in real-time? That'= s a
> pretty serious adversary, so you should clarify here
>

New text:

=C2=A0 =C2=A0STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA= 256,
=C2=A0 =C2=A0which is subject to bid down attacks by an on-path atta= cker that
=C2=A0 =C2=A0would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving onl= y the
=C2=A0 =C2=A0MESSAGE-INTEGRITY attribute and exploiting a potential vulnera= bility.
=C2=A0 =C2=A0Protection of the channel itself, using TLS o= r DTLS, mitigates these
=C2=A0 =C2=A0attacks.=C2=A0 Timely removal of the support of MESSAGE= -INTEGRITY in a
=C2=A0 =C2=A0future version of STUN is necessary.

=
I still don't understand the capabilities you seem to believ= e the attacker has.
Can you describe the exact attack.
=

--0000000000000eb4b1056a790af1-- From nobody Sun Apr 22 19:12: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 114BD1270FC for ; Sun, 22 Apr 2018 19:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, 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 9Q8PVl_NSTj5 for ; Sun, 22 Apr 2018 19:12:34 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 A6BDE12711B for ; Sun, 22 Apr 2018 19:12:33 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id AQy0fZWmHnpflAQy0fuP7L; Mon, 23 Apr 2018 02:12:32 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with SMTP id AQxwfN23TmHJVAQxxfcyJT; Mon, 23 Apr 2018 02:12:31 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w3N2CRm8028862; Sun, 22 Apr 2018 22:12:27 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w3N2CQte028857; Sun, 22 Apr 2018 22:12:26 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Marc Petit-Huguenin Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org In-Reply-To: (marc@petit-huguenin.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 22 Apr 2018 22:12:26 -0400 Message-ID: <8736zmd62d.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBDBfvEX9SjLHp5Zp4ymCroEKvavrnu71N+s32ouA5tgbYagB0ZKANHHLppmGxT3LPtH0kqc71ei9+PIcP8aYlvCz2/g/3xqaij9z+TuxwQ9mNFP3K45 QARJHP4dhzi2NGmUsil5tL+Qx/y4+5oEY3r51XZuqgZIa5AKtT9d0kcnLsW+9ul1eJtSUnvDfya1vnrJ6FaRfDRRxGJt4N6n6LJmT3834A31qClVPbhf62ag dkeeNOAa+QLKigTY5WlvFRuvd6Fsplo891Bkm7xjKhTyJEYvCkqWLnW6bp2THUfr Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 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, 23 Apr 2018 02:12:36 -0000 My apologies for not responding to this sooner: Marc Petit-Huguenin writes: >> 17.1. STUN Security Features Registry >> >> A STUN Security Feature set defines 24 bit as flags. >> >> IANA is requested to create a new registry containing the STUN >> Security Features that are protected by the bid down attack >> prevention mechanism described in section Section 9.2.1. >> >> The initial STUN Security Features are: >> >> Bit 0: Password algorithms >> Bit 1: Username anonymity >> Bit 2-23: Unassigned >> >> Beware that the assignment of features to bits in the security feature >> value has changed! Bit numbers are assigned from the left/high-order >> end -- see figure 2 in the draft. So the *values* for these bits are: >> >> 0x400000 Bit 0: Password algorithms >> 0x200000 Bit 1: Username anonymity >> >> But the values assigned in -15 were: >> >> 0x000001: Password algorithms >> 0x000002: Username anonymity > > Hmm, that was not the intent, and not how I read the text. Even in > Figure 2 less significant bits are on the right. So the intent is > real tat bit0=0x001, bit1 = 0x002, and so on. All we do is about > interoperability, so I added some text that makes that less ambiguous. (The latest posted version is still -16, so I haven't seen the changes you refer to.) In reference to the statements: >> The initial STUN Security Features are: >> >> Bit 0: Password algorithms >> Bit 1: Username anonymity >> Bit 2-23: Unassigned I've skimmed the text again, and it appears that this passage is the only one that allocates the functions "password algorithms" and "username anonymity" to specific bits of the security feature value. Thus, it's critical what "bit 0" means in this context. Searching for "0" in the document, I can find no outright definition of the meaning of "bit 0". However, there are 10 figures in the document, and 8 of them show the numbering of the bits of various fields, with bit "0" being the *high-order*, *most-significant*, "left"-most bit of the field, bit "1" the next-highest-order bit, etc. This numbering seems to be conventional in RFCs. Thus, I recommend that if you really want to persist in calling the low-order bit of the security features field "bit 0", you should explain that very clearly in section 17.1. Dale From nobody Sun Apr 22 20:30:42 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 88378126FB3 for ; Sun, 22 Apr 2018 20:30:41 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 JXF9wf6ylndH for ; Sun, 22 Apr 2018 20:30:37 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 950A3126DED for ; Sun, 22 Apr 2018 20:30:37 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id e20-v6so8977968itc.1 for ; Sun, 22 Apr 2018 20:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MKZzNFz0qNWfyNolYcI4P5s0xqV+tsMh23zcuitAH1M=; b=H687+YsXsYNnz8f3A0SU4011ewMfQ44BklgW9ATSILuHy5vChEJIKHpiizTBIrFiY4 dNwprLlh0gNBY6/wg44rnJ4DfvA8A1E6YbWKg+5HVbnMSOgEu2EQ1l5MDvF+9yHMFnsp WU/YGpJ3hE1Ax7Vg46jA4ozNJE61y09lwwbBM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MKZzNFz0qNWfyNolYcI4P5s0xqV+tsMh23zcuitAH1M=; b=dzVMQHHHwbcLrPko6ti4dXZHHiZcASbFH5KQYhe0e8PGI5Qwm0oJaG9m0tFGKZc9DW zeh7rGGwkVnXm/1Zcd9ncU+LgHcLDYyov7W1AbfeDY6U4mYNI1PpWQKQqtp5Z6OXVsxJ 1RCPf2uWPLuCxyKDh3Xbrq2f7uZ4NTb4zRXqzaB3/eUZwSwtp9VtfZeEbTZqLd0olQzh kvT3/oNimweDIz0VWYEwE0xP5QYzWrD5mDj7FkKwMJ/p3vThazjVbwnLjx4mX60LgWTR xYidltecV9csdBpqOGmai2fqKDf30M3pAo3DbjrGyg4pMUu54PFogEQ6A2y3foBvpg8k FXnQ== X-Gm-Message-State: ALQs6tAc5oDneMLyzuKJqtLWlcnvN+pqxb38FbeFsRtZy2URcWUMbov1 7A1VxGE5glFqFj/RirDrJAV7vw== X-Google-Smtp-Source: AIpwx48Ta84BuBAdUttmgt0oIkH1LpMrAGHMebsvz2cbscRNS+koHIZASA+mISZbWaqnNeTNAQg4zQ== X-Received: by 2002:a24:730e:: with SMTP id y14-v6mr13111024itb.45.1524454236939; Sun, 22 Apr 2018 20:30:36 -0700 (PDT) Received: from aither.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id k141-v6sm3556604ite.41.2018.04.22.20.30.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Apr 2018 20:30:36 -0700 (PDT) To: Marc Petit-Huguenin , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> From: Peter Saint-Andre Message-ID: <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> Date: Sun, 22 Apr 2018 21:30:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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, 23 Apr 2018 03:30:41 -0000 On 4/21/18 3:39 PM, Marc Petit-Huguenin wrote: >>>>> Section 6.3.4 states: >>>>> >>>>> o If the error code is 500 through 599, the client MAY resend the >>>>> request; clients that do so MUST limit the number of times they do >>>>> this. >>>>> >>>>> It is reasonable to provide guidance as to the number of re-sends? >>>> >>>> Same issue here, that's a section that is unmodified from RFC 5389. >>> >>> I understand. Now is our chance to fix it. :-) >>> >>>> As long as the client does not enter an endless loop of retransmission, choosing different numbers of re-sends does not affect interoperability. >>> >>> Choosing different numbers is OK, but choosing an infinite number is >>> not. Can we provide guidance as to how many is too many? 10? 50? 100? >> >> Well, the text already states that an infinite number of of re-sends is not compliant. Anyway, I am not sure how to determine a reasonable number, but I'll try. > > I chose 4 as the maximum number of retransmissions. I based that on error code 508 in TURN that defines a delay of 60 seconds between retransmissions, so we now get a delay of 5 minutes before the client gives up in case of insufficient capacity. The new text reads like this: > > "o If the error code is 500 through 599, the client MAY resend the > request; clients that do so MUST limit the number of times they do > this. Unless a specific error code specifies a different value, > the number of retransmissions MUST be limited to 4." > "SHOULD be limited to 4" seems fine, but MUST is OK too. Thanks for looking into this and making the fix. Peter From nobody Mon Apr 23 02:52:39 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 65D64124D68 for ; Mon, 23 Apr 2018 02:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 i2X4nFoXg0Tm for ; Mon, 23 Apr 2018 02:52:36 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A0B1200A0 for ; Mon, 23 Apr 2018 02:52:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=ipNOLDRSaNr6jdcGD+yhzz42XflaNqcLpzd0SyvQmldyTHo/7fHpoRJJK9/Oqfd1ZZlW+tKQ2AuEfL6sttRYYlQfeublKV04Xlp+s2GCQ1IxpS6LAjThDCGZV/kdhOGEbCXlS91aJJU1vkb3W0YkuChgyrTrzgeMBxkuFz8PNJo=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 21635 invoked from network); 23 Apr 2018 11:51:33 +0200 Received: from 100.1.71.37.rev.sfr.net (HELO ?10.188.94.233?) (37.71.1.100) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Apr 2018 11:51:33 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <5d8e3d9e-46bd-57ba-5c80-ff414ef2aca5@petit-huguenin.org> Date: Mon, 23 Apr 2018 11:51:32 +0200 Cc: The IESG , tram-chairs@ietf.org, Tolga Asveren , Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152390695800.19624.250040937113641569.idtracker@ietfa.amsl.com> <5d8e3d9e-46bd-57ba-5c80-ff414ef2aca5@petit-huguenin.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.3445.6.18) X-PPP-Message-ID: <20180423095133.21625.84400@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram?= =?utf-8?q?-stunbis-16=3A_=28with_COMMENT=29?= 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, 23 Apr 2018 09:52:38 -0000 Thanks! > Am 22.04.2018 um 20:39 schrieb Marc Petit-Huguenin = : >=20 > Hi Mirja, >=20 > Thanks for the review, please see my responses inline. >=20 > On 04/16/2018 12:29 PM, Mirja K=C3=BChlewind wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-tram-stunbis-16: Yes >>=20 > [...] >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> 1) Maybe it would make sense to refer informationally to >> draft-ietf-tram-stun-pmtud in section 6.1? >=20 > Done, here's the new last paragraph: >=20 > STUN provides no ability to handle the case where the request is > under the MTU but the response would be larger than the MTU. It is > not envisioned that this limitation will be an issue for STUN. The > MTU limitation is a SHOULD, and not a MUST, to account for cases > where STUN itself is being used to probe for MTU characteristics > [RFC5780]. See also [I-D.ietf-tram-stun-pmtud] for a framework that > use STUN to add Path MTU Discovery to protocols that lack one. > Outside of this or similar applications, the MTU constraint MUST be > followed. >=20 >>=20 >> 2) sec 6.2.2: This sentence seems to assume that only one request is = sent per >> TCP connection/each request sends out after a new SYN: "However, for = a >> request/response transaction, if the client has not >> received a response by Ti seconds after it sent the SYN to = establish >> the connection, it considers the transaction to have timed out.=E2=80= =9C >> i don=E2=80=99t think that assumption would be correct. Maybe = rephrase this sentence=E2=80=A6? >=20 > Right, the Ti timer should start when the unique request per = transaction is sent, not when the connection is established. Here's the = new text: >=20 > Reliability of STUN over TCP and TLS-over-TCP is handled by TCP > itself, and there are no retransmissions at the STUN protocol level. > However, for a request/response transaction, if the client has not > received a response by Ti seconds after it sent the request message, > it considers the transaction to have timed out. Ti SHOULD be > configurable and SHOULD have a default of 39.5s. This value has = been > chosen to equalize the TCP and UDP timeouts for the default initial > RTO. >=20 >=20 >>=20 >> 3) Also section 6.2.2: Should the client send keep-alives if a = connection is >> hold open but currently not used? If not, I guess further = recommendation is >> needed to address the case where a transmission fails because an = existing idle >> TCP connection was used that doesn=E2=80=99t work anymore. In this = case, I'd say the >> recommendation would be to send a RST and try to open a new TCP = connection. >=20 > I feel that keep-alives recommendations are dependent on the = specificity of a STUN Usage, and should be left to the document = specifying it. For example in the TURN case there is probably enough = frequent messages with the allocation and permission refresh to not = mandate any kind of keep-alive. OTOH for Basic STUN Usage (NAT = discovery) a client will probably immediately close the TCP connection = after retrieving the NAt transport address. >=20 > So I added TCP keep-alive to the list of what STUN Usages should = discuss (Section 13): >=20 > o The keep-alive mechanism if STUN is run over TCP or TLS-over-TCP. >=20 > I also added the following paragraph to section 6.2.2: >=20 > The details of an eventual keep-alive mechanism are left to each = STUN > Usage. In any case if a transaction fails because an idle TCP > connection doesn't work anymore the client SHOULD send a RST and try > to open a new TCP connection. >=20 > and I updated the Basic Usage to follow our own recommendations: >=20 > [...] > ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP > and TCP. It MAY support STUN over TCP/TLS or ALTERNATE-SERVER = mechanism for the same reason. It MUST support UDP > and TCP. It MAY support STUN over TCP/TLS or STUN over UDP/DTLS; > however, DTLS and TLS provide minimal security benefits in this = basic > mode of operation. It does not require a keep-alive mechanism as a > TCP or TLS-over-TLS connection is closed after the end of the = Binding > transaction. It MAY utilize the FINGERPRINT mechanism but MUST NOT > STUN over UDP/DTLS; > however, DTLS and TLS provide minimal security benefits in this = basic > mode of operation. It does not require a keep-alive mechanism as a > TCP or TLS-over-TLS connection is closed after the end of the = Binding > transaction. It MAY utilize the FINGERPRINT mechanism but MUST NOT > [...] >=20 >>=20 >> 4) Should section 9.2 maybe provide further guidance on the lifetime = of the >> (server-selected) nonce? >=20 > I added this in the Security Considerations Section: >=20 > Implementations and deployments of a STUN usage using the Long-Term > Credential Mechanism (Section 9.2) MUST follow the recommendations = in > Section 5 of [RFC7616]. >=20 >>=20 >> 5) I'm sure, I just missed something but how does a server know if a = first >> request intends to use the Long-Term Credential Mechanism or not (see = 9.2.3.1. >> and 9.2.4 I guess). Or is this pre-configured? >=20 > Each STUN Usage defines what authentication mechanism it uses (see = bullet point 3 of section 13), so a server implementing a specific Usage = knows what to do with the first request. >=20 >>=20 >> 6) Section 6.3 says that this doc only specifies the procedures for = the new >> spec in this document and subsequently says: "It checks [...] that = the magic >> cookie field has the correct value..." However, given this spec = obsoletes >> RFC5389, I think that section 11 should provide more guidance on how = to handle >> "old" STUN messages. Or is the intention that an upgraded STUN server = does not >> handle old requests anymore? If so that should be spelled out as = well. >=20 > STUNBis still contains the processing of "classic" STUN (aka RFC5389), = which is what "old" STUN messages are (not RFC5389 messages). >=20 >>=20 >> 7) sec 14.5: "The value of the MESSAGE-INTEGRITY attribute is set to = a dummy >> value." Should the dummy value be further specified? Also it looks = like there >> was a compile problem on page 39. Is there text missing? >=20 > Already responded to that point in Dale Worley review: >=20 > "[...] the input is up to and including the attribute *preceding* the = MESSAGE-INTEGRITY attribute. The message attribute is only counted when = calculating the length in the header [...] > [...] the content of the MESSAGE-INTEGRITY is not used when computing = the hash, so the content itself is irrelevant." >=20 > The text says: >=20 > The text used as input to HMAC is the STUN message, up to and > including the attribute preceding the MESSAGE-INTEGRITY-SHA256 > attribute. =20 >=20 >>=20 >> 8) sec 17.6: Isn't "stuns 5349/upd" used for DTLS? If so, it should = be >> registered! >>=20 >>=20 >=20 > Answered by Adam Roach. >=20 > --=20 > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug >=20 From nobody Mon Apr 23 07:20:57 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 21158127978; Mon, 23 Apr 2018 07:20:52 -0700 (PDT) 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.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152449325211.21886.16366690442756908271@ietfa.amsl.com> Date: Mon, 23 Apr 2018 07:20:52 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-turnbis-17.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, 23 Apr 2018 14:20:52 -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-17.txt Pages : 84 Date : 2018-04-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-17 https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-17 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 Mon Apr 23 07:30:38 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 319B51270A7 for ; Mon, 23 Apr 2018 07:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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_SORBS_WEB=1.5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 6BWCziIv4hys for ; Mon, 23 Apr 2018 07:30:34 -0700 (PDT) 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 7D842126D74 for ; Mon, 23 Apr 2018 07:30:34 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1524493834; 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-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: x-microsoft-antispam-message-info:spamdiagnosticoutput: spamdiagnosticmetadata:Content-Type:Content-Transfer-Encoding: MIME-Version:X-MS-Office365-Filtering-Correlation-Id: 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=a nNQvS7DUGPkrvFpAJTb6191nIjI6aJwxhtrUQIvjK M=; b=mNR/AK5jG6uQRWg6rsrnOVtE5fgZ2ioZQ3kowHkFksy9 VJ8Ybs7LKunojp5KNP8JktcKQ8/xjNDsLF33yrN4eyuGijaGt9 MLv2PlL6Af0mrxI3lxHqCUhOCPL/KLnPPODUgdQWiPpj1vX1Sj DmJ4V+moL5W3bhhSNawSUbbwW8E= 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 1f27_2b6a_8cd1b9fd_81dc_4e3f_bd63_f775c66657f5; Mon, 23 Apr 2018 09:30:33 -0500 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; Mon, 23 Apr 2018 08:29:55 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 23 Apr 2018 08:29:54 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 23 Apr 2018 08:29:54 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 23 Apr 2018 08:29:53 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1394.namprd16.prod.outlook.com (10.172.207.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.12; Mon, 23 Apr 2018 14:29:52 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067%3]) with mapi id 15.20.0696.017; Mon, 23 Apr 2018 14:29:51 +0000 From: "Konda, Tirumaleswar Reddy" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-17.txt Thread-Index: AQHT2w5k5Ye43UtxsU6plD0Ba+ptDKQOZzcQ Date: Mon, 23 Apr 2018 14:29:51 +0000 Message-ID: References: <152449325211.21886.16366690442756908271@ietfa.amsl.com> In-Reply-To: <152449325211.21886.16366690442756908271@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.300.84 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=McAfee.com; x-originating-ip: [122.172.136.145] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1394; 7:7V6/+FQsBhxnNXUbOwBLfBuSRZVH2kEe0i9sJAzrBwYOLOLLaFak7d7fAONvZnsFUUIkYp1Otvac704t40V2medDGlR6yAm+fN9Iv5O05ot7TiDlufZlCWB9Xkv+WXuANrLx3aI5oOJT9+u09GBEkVrq1j3uAUMYCg32Tiq6zjrKarvVEl8CT11+ccDbGODZKfB+t4W10FwKMFulN7yS8ADgItqFUj+48P9dWXaEUAGAnlp6W4vGlE4r5cVn7ob7 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1394; x-ms-traffictypediagnostic: BN6PR16MB1394: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231232)(944501410)(52105095)(10201501046)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1394; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1394; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(366004)(396003)(39380400002)(13464003)(377424004)(1730700003)(81166006)(8676002)(8936002)(3660700001)(76176011)(2900100001)(7696005)(316002)(229853002)(86362001)(3280700002)(2351001)(6916009)(6116002)(3846002)(305945005)(74316002)(5660300001)(476003)(478600001)(966005)(6306002)(72206003)(9686003)(53936002)(2501003)(7736002)(5250100002)(6246003)(446003)(11346002)(186003)(55016002)(5640700003)(33656002)(26005)(2906002)(80792005)(53546011)(6506007)(102836004)(55236004)(6436002)(25786009)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1394; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: CSexOsoe3za0jkoHcL4lH/w9YRy/YZFR1DBJASkJP6diE7m/GQSaAIPXF+G/NMufnhUkvmmd++mgKcVBa4qgRs6n0vve11pLu7jpoM0dbv9vZAnPoLcg/2lIvJm7o4F066KGUAcTzz+NmWK1tt9yB8HIk4vCuNDCE2OpGj+hcueef0PtUsETSXb6cqCSKSIa spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: dda084a3-ec25-4f5f-9b7a-08d5a926acf7 X-MS-Exchange-CrossTenant-Network-Message-Id: dda084a3-ec25-4f5f-9b7a-08d5a926acf7 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 14:29:51.7782 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1394 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 <6270> : inlines <6580> : streams <1784866> : uri <2630370> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-17.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, 23 Apr 2018 14:30:36 -0000 Updated draft allows the TURN server to forward inbound STUN connectivity c= hecks without permissions and also addresses the comments from Noriyuki Tor= ii. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, April 23, 2018 7:51 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-17.txt >=20 >=20 >=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 IE= TF. >=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-17.txt > Pages : 84 > Date : 2018-04-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-17 > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-17 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-17 >=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 Mon Apr 23 10:11:23 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 0698C12D87A; Mon, 23 Apr 2018 10:11:06 -0700 (PDT) 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 lkzJ_X5hXz-7; Mon, 23 Apr 2018 10:11:04 -0700 (PDT) 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 3CFF312D7F1; Mon, 23 Apr 2018 10:11:04 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55] (unknown [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55]) (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 A952CAE844; Mon, 23 Apr 2018 19:11:00 +0200 (CEST) From: Marc Petit-Huguenin To: "Dale R. Worley" Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <8736zmd62d.fsf@hobgoblin.ariadne.com> Message-ID: <0de8c1fd-ab42-6ea2-e04e-eba05f5848df@acm.org> Date: Mon, 23 Apr 2018 10:10:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <8736zmd62d.fsf@hobgoblin.ariadne.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8SJmvjBhWeUVNUIZyXuhSAgyRXqRQ0Vf6" Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 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, 23 Apr 2018 17:11:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8SJmvjBhWeUVNUIZyXuhSAgyRXqRQ0Vf6 Content-Type: multipart/mixed; boundary="mkQ5e8Udj8dtnXuIxPdOlXP2oA1SKisWp"; protected-headers="v1" From: Marc Petit-Huguenin To: "Dale R. Worley" Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: <0de8c1fd-ab42-6ea2-e04e-eba05f5848df@acm.org> Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 References: <8736zmd62d.fsf@hobgoblin.ariadne.com> In-Reply-To: <8736zmd62d.fsf@hobgoblin.ariadne.com> --mkQ5e8Udj8dtnXuIxPdOlXP2oA1SKisWp Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/22/2018 07:12 PM, Dale R. Worley wrote: > My apologies for not responding to this sooner: >=20 > Marc Petit-Huguenin writes: >>> 17.1. STUN Security Features Registry >>> >>> A STUN Security Feature set defines 24 bit as flags. >>> >>> IANA is requested to create a new registry containing the STUN >>> Security Features that are protected by the bid down attack >>> prevention mechanism described in section Section 9.2.1. >>> >>> The initial STUN Security Features are: >>> >>> Bit 0: Password algorithms >>> Bit 1: Username anonymity >>> Bit 2-23: Unassigned >>> >>> Beware that the assignment of features to bits in the security featur= e >>> value has changed! Bit numbers are assigned from the left/high-order= >>> end -- see figure 2 in the draft. So the *values* for these bits are= : >>> >>> 0x400000 Bit 0: Password algorithms >>> 0x200000 Bit 1: Username anonymity >>> >>> But the values assigned in -15 were: >>> >>> 0x000001: Password algorithms >>> 0x000002: Username anonymity >> >> Hmm, that was not the intent, and not how I read the text. Even in >> Figure 2 less significant bits are on the right. So the intent is >> real tat bit0=3D0x001, bit1 =3D 0x002, and so on. All we do is about >> interoperability, so I added some text that makes that less ambiguous.= >=20 > (The latest posted version is still -16, so I haven't seen the changes > you refer to.) Sorry, I should have pasted the text. But the point is moot, see below. >=20 > In reference to the statements: >=20 >>> The initial STUN Security Features are: >>> >>> Bit 0: Password algorithms >>> Bit 1: Username anonymity >>> Bit 2-23: Unassigned >=20 > I've skimmed the text again, and it appears that this passage is the > only one that allocates the functions "password algorithms" and > "username anonymity" to specific bits of the security feature value. > Thus, it's critical what "bit 0" means in this context. >=20 > Searching for "0" in the document, I can find no outright definition of= > the meaning of "bit 0". However, there are 10 figures in the document,= > and 8 of them show the numbering of the bits of various fields, with bi= t > "0" being the *high-order*, *most-significant*, "left"-most bit of the > field, bit "1" the next-highest-order bit, etc. This numbering seems t= o > be conventional in RFCs. I did some research and you were right, starting from the left side is mo= re common. My main counter-example is in fact in STUN itself as figure 3= : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ |M |M |M|M|M|C|M|M|M|C|M|M|M|M| |11|10|9|8|7|1|6|5|4|0|3|2|1|0| +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ And as the base64 encoding is done on an array of bytes and not an intege= r, it is in fact simpler to define it that way. The new text in section n= ow reads: Bits are assigned starting from the most significant side of the bit set, so Bit 0 is the leftmost bit and Bit 23 the rightmost bit. I also updated the example in Appendix B.1. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --mkQ5e8Udj8dtnXuIxPdOlXP2oA1SKisWp-- --8SJmvjBhWeUVNUIZyXuhSAgyRXqRQ0Vf6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlreE6IACgkQKcRFldZq fsS9Xw//TmWsd5Vpr3rhSNNFREndNouHVG+P5whqzVcB9qeCDcybvOmQ4Fie7Ebd lewuSW0GJbEJFvhLonYxvzrn7Lr9zKSwJZA5g7lKdVCpEoLxzli0bwIJJb1YVS6N oTnT2tFzvc2DAcKtQ7Vn/wvYm9Z+LWojKXeJkLdXBem802goZOjlMVL8rjZR8j0h jKDv9hkwDgKkoAiFgPuPpH5fMsgfb5NF+gqG0fdPmR5tPoUr1OJTXzJmL9zurhaf /LGpfFnUK7MwMHrvbNpKa232rwuayJPAZSsfbMF0D3f7hjcsR4uIbnY/8V1SYVCn OrWAUJv6YNUTQoA2c2ZvUB/PwDuBd+HBez8P18ZyuG0Bw92HlhjX/xaot/bDJIiV UhHh+5oZ/57EqSwvUTWYUTShN3Xz1m9CbtVNDFMwup5ugopbxhkFoePQc5GGiKBi /0g1rtOv7lPuN90nXdtdPS257QoWwmdUcQZjmrANL7HabwJMUfSCOzbzSIP2rifT s5wHywcmSYMFqMQ5Hqvoz5Maa31QGq4yJaIbuKyKa8siqARj46bIeKZAsvZQyHAo ElxwDc2brWumAW3of6tceCpHik3UwatM2ctz7PPP80icXUkjy+E9opoezDbsAYUW D1huUYLp9gGH4KYpN6Cv2RVKr9+kZk3Sgg35LIVorO1s02A9eZs= =1JkA -----END PGP SIGNATURE----- --8SJmvjBhWeUVNUIZyXuhSAgyRXqRQ0Vf6-- From nobody Mon Apr 23 10:46:16 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 D888512D88A; Mon, 23 Apr 2018 10:46:08 -0700 (PDT) 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 HPBso3AI8B1S; Mon, 23 Apr 2018 10:46:07 -0700 (PDT) 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 C885312D889; Mon, 23 Apr 2018 10:46:06 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55] (unknown [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55]) (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 747AAAE844; Mon, 23 Apr 2018 19:46:04 +0200 (CEST) To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> From: Marc Petit-Huguenin Message-ID: Date: Mon, 23 Apr 2018 10:46:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HbSK1bmpKHBO7Al1fHJB33Ot8fFkTISvn" Archived-At: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 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, 23 Apr 2018 17:46:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HbSK1bmpKHBO7Al1fHJB33Ot8fFkTISvn Content-Type: multipart/mixed; boundary="y7NgICYfHnsZAft52uUF0RpGrT5GMGr2M"; protected-headers="v1" From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> In-Reply-To: <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> --y7NgICYfHnsZAft52uUF0RpGrT5GMGr2M Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/22/2018 08:30 PM, Peter Saint-Andre wrote: > On 4/21/18 3:39 PM, Marc Petit-Huguenin wrote: >=20 >>>>>> Section 6.3.4 states: >>>>>> >>>>>> o If the error code is 500 through 599, the client MAY resend = the >>>>>> request; clients that do so MUST limit the number of times t= hey do >>>>>> this. >>>>>> >>>>>> It is reasonable to provide guidance as to the number of re-sends?= >>>>> >>>>> Same issue here, that's a section that is unmodified from RFC 5389.= =20 >>>> >>>> I understand. Now is our chance to fix it. :-) >>>> >>>>> As long as the client does not enter an endless loop of retransmis= sion, choosing different numbers of re-sends does not affect interoperabi= lity. >>>> >>>> Choosing different numbers is OK, but choosing an infinite number is= >>>> not. Can we provide guidance as to how many is too many? 10? 50? 100= ? >>> >>> Well, the text already states that an infinite number of of re-sends = is not compliant. Anyway, I am not sure how to determine a reasonable nu= mber, but I'll try. >> >> I chose 4 as the maximum number of retransmissions. I based that on e= rror code 508 in TURN that defines a delay of 60 seconds between retransm= issions, so we now get a delay of 5 minutes before the client gives up in= case of insufficient capacity. The new text reads like this: >> >> "o If the error code is 500 through 599, the client MAY resend the >> request; clients that do so MUST limit the number of times they do= >> this. Unless a specific error code specifies a different value, >> the number of retransmissions MUST be limited to 4." >> >=20 > "SHOULD be limited to 4" seems fine, but MUST is OK too. >=20 Changed to SHOULD. Thanks. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --y7NgICYfHnsZAft52uUF0RpGrT5GMGr2M-- --HbSK1bmpKHBO7Al1fHJB33Ot8fFkTISvn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlreG9oACgkQKcRFldZq fsSzgw/9FPTE64+ikRn7y1J24OVVsWIX4BaF1jB4c5wsFxAFTklcN0XkSpDaLvRk uHBdFXpj4Ce+LnmIPKl95s8udekCBkewQkkJE0uuMgCBJHeIjKZq+V81dfgUUcBc pCS2U8GAuP7+NRmfejLxPVLiGexS+mU7azzhwcDaYVFShZmmJcc5fl+wMEk5PKCw NeuP2i2O7p32oCW/Yis95qwtIYikplZ9acbUMRNlnpjHDNCn8/EJAqehiY8mUQsK kf8ldpymzZ59rEpAhdmapHdB/l3NsYDIQzrWCvM6uZjsXiad0IHMimgI2c/ZgCUD LwmTtbK6Kn3PSHWvoSG06oVo1QP8gC+dRbCVC36pZwQjPzgZjeMJYjp3eHA+CEJK iiFNV2RwBNmAVAdELw4qJzC+i2f30SX/JUWkFqCSBAdTWilY72lDI6HLSeo3jyaD XXDFkpXZT1qVL+jnOuKNvCN7S8pqjAghDnE4RulL5zA3h6qofARIizWJkvNsu+Ul m+L53HbWHNXBma4c0enK0b6lKo/c5lYNcwq+ZLpj3NG2WryPB3mS6idsbT39YZ+J diPqO4mw2D6DNjPEA4n1Kv41ImGDZCXCfm7rS6DBXaSDyDf+Z1+dZ/4x4qfEHu9k BiwZE1qrPtWz5TTifqpMctOO1i79ndDqryoAGPef4iaqrHA2/sY= =jhrk -----END PGP SIGNATURE----- --HbSK1bmpKHBO7Al1fHJB33Ot8fFkTISvn-- From nobody Mon Apr 23 11:17:02 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 40A3612D887; Mon, 23 Apr 2018 11:17:00 -0700 (PDT) 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 qH9NkZOpP8wN; Mon, 23 Apr 2018 11:16:57 -0700 (PDT) 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 E9BF2126C0F; Mon, 23 Apr 2018 11:16:56 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55] (unknown [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55]) (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 EDFB9AE844; Mon, 23 Apr 2018 20:16:53 +0200 (CEST) To: Eric Rescorla Cc: tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> Date: Mon, 23 Apr 2018 11:16:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="APSC6FpkQJfx6d3dxvkhOX6rwdS1E9YP0" Archived-At: Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) 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, 23 Apr 2018 18:17:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --APSC6FpkQJfx6d3dxvkhOX6rwdS1E9YP0 Content-Type: multipart/mixed; boundary="DN04mAEdtoqLc52p02G3VCRraVlSCJIFI"; protected-headers="v1" From: Marc Petit-Huguenin To: Eric Rescorla Cc: tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org Message-ID: <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> In-Reply-To: --DN04mAEdtoqLc52p02G3VCRraVlSCJIFI Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/22/2018 05:22 PM, Eric Rescorla wrote: > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin = > wrote: >=20 >> >>>> For a request or indication message, the agent MUST include the= >>>> USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY >> attributes >>>> in the message unless the agent knows from an external indicati= on >>>> which message integrity algorithm is supported by both agents. = In >>>> this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 = MUST >>>> be included in addition to USERNAME. The HMAC for the MESSAGE-= >>> >>> This text appears to conflict with S 7.3 of 5245-bis, which says: >> >> [text missing] >> >> Hmm, no, RFC245bis is still referencing RFC5389, so the procedure for >> stunbis does not apply. >> >=20 > I hear what you're saying, but publishing two documents at the same tim= e > which > make contrary recommendations about the same basic protocol is un-good.= Sure, but wouldn't it be simpler to have rfc5245bis using stunbis and hav= e them updating their text, more than adding some tortuous text in stunbi= s? >=20 >=20 >>> The STUN usage must specify which transport protocol is used, an= d >> how >>>> the agent determines the IP address and port of the recipient. >>>> Section 8 describes a DNS-based method of determining the IP >> address >>>> and port of a server that a usage may elect to use. STUN may b= e >> used >>>> with anycast addresses, but only with UDP and in usages where >>>> authentication is not used. >>> >>> Why this restriction? You should be able to use anycast with long-ter= m >>> AUTH for (say) TURN. >> >> https://www.ietf.org/mail-archive/web/behave/current/msg03582.html >> >> I think that the decision of permitting Anycast should be left to each= >> STUN Usage. Basic STUN Usage does not use authentication and use only= a >> one round trip for the Binding transaction, so Unicast can be used. >> >=20 >> OTOH, TURN and ICE should probably say something about that, so I adde= d a >> new bullet point in Section 13: >> >> o If Anycast addresses can be used for the server in case TCP or >> TLS-over-TCP, or authentication are used. >> >=20 > Are you leaving this text in? That seems very confusing. In isolation yes, but I think it makes sense which the text before the bu= llet points: A STUN usage defines how STUN is actually utilized -- when to send requests, what to do with the responses, and which optional procedures defined here (or in an extension to STUN) are to be used. A usage also defines: [...] o If Anycast addresses can be used for the server in case TCP or TLS-over-TCP, or authentication are used. >=20 >=20 >>>> transaction over UDP or DTLS-over-UDP is also considered failed= if >>>> there has been a hard ICMP error [RFC1122]. For example, assum= ing >> an >>>> RTO of 500ms, requests would be sent at times 0 ms, 500 ms, 150= 0 >> ms, >>>> 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has no= t >>>> received a response after 39500 ms, the client will consider th= e >>>> transaction to have timed out. >>> >>> I note that these recommendations now seem crazily long. I assume the= >>> WG had consensus on this, but I wanted to note it. >> >> Not just the WG, also the IESG that approved RFC 5389 too as, but for = the >> addition of "or DTLS-over-UDP", this is the same text than in RFC 5389= =2E >> >=20 > Yes, I know. My point is that while they might have bee sensible when > 5389 was published they *now* seem crazily long. Did the WG explicitly > decide not to update them? No, nobody ever suggested that there was an issue there. >=20 >=20 >=20 >=20 >>>> ALTERNATE-SERVER where authentication of the response is not >> possible >>>> or practical. If the transaction uses TLS or DTLS and if the >>>> transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 >> attribute >>>> and if the server wants to redirect to a server that uses a >> different >>>> certificate, then it MUST include an ALTERNATE-DOMAIN attribute= >>>> containing the subjectAltName of that certificate. >>> >>> 1. Why is MESSAGE-INTEGRITY-SHA256 relevant here? >> >> ALTERNATE-DOMAIN exists only since stunbis, so the >> MESSAGE-INTEGRITY-SHA256 acts as a flag indicating that 1) the transac= tion >> is authenticated and 2) that the client understand that new attribute.= >> >=20 > This would be good to explain. New text: [...] containing the subjectAltName of that certificate. The test on the MESSAGE-INTEGRITY-SHA256 attribute indicates that the transaction is authenticated and that the client implements this specification and so can process the ALTERNATE-DOMAIN attribute. >=20 >=20 >>>> o What authentication and message-integrity mechanisms are use= d. >>>> >>>> o The considerations around manual vs. automatic key derivatio= n >> for >>>> the integrity mechanism, as discussed in [RFC4107]. >>>> >>>> o What mechanisms are used to distinguish STUN messages from o= ther >>> >>> Why is this required? It seems like that's a generic STUN feature. >> >> That text is identical to the text in RFC 5389. RFC 5764/7983 is one = such >> mechanism, but there is nothing that prevent another protocol stack to= use >> a different mechanism (inference, shim, etc...) >> >=20 > But ultimately no matter what the other protocol provides for demux, ST= UN > has its > own demux. In fact I think that the reason for that item was because FINGERPRINT can= also be used to demux STUN traffic, but it is optional. So an STUN Usag= e needs to tell if FINGERPRINT is mandatory (like in ICE). >=20 >=20 >>> transport protocol uses TLS or DTLS. >>>> >>>> The value of ALTERNATE-DOMAIN is variable length. It MUST be a= >> UTF-8 >>>> [RFC3629] encoded sequence of less than 128 characters (which c= an >> be >>>> as long as 509 bytes when encoding them and as long as 763 byte= s >> when >>>> decoding them). >>> >>> Is it an A-label or a U-label? >> >> I do not know. What would you suggest? >> >=20 > I believe Alexey raised this separately, so I would refer to his commen= ts. >=20 >> >>> >>>> that is not readily subject to offline dictionary attacks. >>>> Protection of the channel itself, using TLS or DTLS, mitigates >> these >>>> attacks. >>>> >>>> STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA2= 56, >>>> which is subject to bid down attacks by an on-path attacker. >>> >>> By an on-path attacker who can forge HMAC-SHA1 in real-time? That's a= >>> pretty serious adversary, so you should clarify here >>> >> >> New text: >> >> STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, >> which is subject to bid down attacks by an on-path attacker that >> would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving only the= >> MESSAGE-INTEGRITY attribute and exploiting a potential vulnerabilit= y. >> Protection of the channel itself, using TLS or DTLS, mitigates thes= e >> attacks. Timely removal of the support of MESSAGE-INTEGRITY in a >> future version of STUN is necessary. >> >=20 > I still don't understand the capabilities you seem to believe the attac= ker > has. > Can you describe the exact attack. >=20 1. Vulnerability is found in HMAC-SHA1 2. Client Alice still supports M-I and M-I-256, does not know what versio= n of STUN server Bob supports and so send both. 3. On-path attacker removes M-I-256. 5. stunbis server Bob thinks that Alice is an RFC 5389 client and continu= e with that protocol. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --DN04mAEdtoqLc52p02G3VCRraVlSCJIFI-- --APSC6FpkQJfx6d3dxvkhOX6rwdS1E9YP0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlreIxQACgkQKcRFldZq fsTY9RAA0RkWgK7chUdtZ53m127DgxriDzMBwgtVYIJH3DxXlD/bupagZCL1IauV zpDtj2cpcbzIV67V+jluVQ9XrH5d1vhJm8y1gE5ESmkt3DxbDBumMOu89HZZFMsw sQp+ApJ3M+9JCXoKAkAHJJGcu6mqLg+ObPuXvXjI7uWA4p33LlkwD/b9jffzbTvY 08g/SjwAstzgFzme5VJbHphv6Q4qQwnBW24c5Jh5alJ9H4UbRRj2D2Z8SkaexIAJ yFEFVV5ECGolwXvINax+ee9r4LwYmII/OuWDY+PVgBT08SR9vQPiwp6leVehx1Jn MiBLy+6e/tLPt+RgP/kafb7FdVg4qOvCBuVdx5UM0kW2uQM02MgGP6VUgRVLzoPD /Lh2wbeNiqhoWMuUzLnw6+KNsbCQbNcHIu26MDs9d6ctV+bI97YFAXXXPd17l/vu VJTonmULlXvk9WKVdzTQwC4ryCRiM9XVzxdeG0qt5F8yWkPgXbn0abkOHx3/KCZc d8zK0qk31mmSJL6hfNYyIV9xN++QdnceBrgxfJGowa4gunO25vhaLKa68SzVHSYg IaaydXgXXUEJutKDca12M1HBmzmCw9LP6NZJ9hQmzDilJYAAw+MidPAnWpG7ZAtL GMWKKKbUrDZ91qeQgPYoF273J+AHEczX0ItSdgK/5FGQ0edcFxE= =KiNf -----END PGP SIGNATURE----- --APSC6FpkQJfx6d3dxvkhOX6rwdS1E9YP0-- From nobody Mon Apr 23 15:38:10 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 6C96D12DA09; Mon, 23 Apr 2018 15:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] 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 GNRuEXTMio90; Mon, 23 Apr 2018 15:38:06 -0700 (PDT) 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 CE414124319; Mon, 23 Apr 2018 15:38:05 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55] (unknown [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55]) (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 CBBB8AE844; Tue, 24 Apr 2018 00:38:01 +0200 (CEST) From: Marc Petit-Huguenin To: Adam Roach , The IESG Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tram@ietf.org References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> Message-ID: <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> Date: Mon, 23 Apr 2018 15:37:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WyL8e6MSsPUzAUkT5hfNEdfZRPuZT3r00" Archived-At: Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) 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, 23 Apr 2018 22:38:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WyL8e6MSsPUzAUkT5hfNEdfZRPuZT3r00 Content-Type: multipart/mixed; boundary="JmjH6IndchCkgqBMpkRh5aqirYwtInqBR"; protected-headers="v1" From: Marc Petit-Huguenin To: Adam Roach , The IESG Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tram@ietf.org Message-ID: <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> Subject: Re: Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> In-Reply-To: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> --JmjH6IndchCkgqBMpkRh5aqirYwtInqBR Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Adam, Thanks for the review, please see my responses inline. This is also the last review I can process until Saturday 28. The remain= ing of the work to do on stunbis is: - process Alexey Melnikov review - process Process Benjamin Kaduk review - add text for Dale Worley point on IPv6 NAT - add text explaining the bid-attack protection mechanism - work on answer to =C2=A76.2.3 below - answer additional concerns following my responses - final review for language - publish -17 On 04/17/2018 11:03 PM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-tram-stunbis-16: Discuss >=20 [...] >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks to everyone who worked on this revision of the STUN protocol. Th= anks in > particular to the ARTART reviewer and to the authors for actively engag= ing on > the points he raised. >=20 > I have one concern about interoperability and another about the IANA ch= anges > that I believe require changes to the document prior to publication. >=20 > =C2=A714.2: >=20 >> X-Port is computed by taking the mapped port in host byte order, >> XOR'ing it with the most significant 16 bits of the magic cookie, and= >> then the converting the result to network byte order. If the IP >> address family is IPv4, X-Address is computed by taking the mapped IP= >> address in host byte order, XOR'ing it with the magic cookie, and >> converting the result to network byte order. If the IP address >> family is IPv6, X-Address is computed by taking the mapped IP address= >> in host byte order, XOR'ing it with the concatenation of the magic >> cookie and the 96-bit transaction ID, and converting the result to >> network byte order. >=20 > The discussion of performing operations "in host byte order" is very co= nfusing, > and seems likely to cause issues communicating between machines of diff= erent > endianness. As an implementor, based on this description, I cannot tell= > whether, given a port of 0x1234 (and operating on a little-endian machi= ne), > I'm supposed to do: >=20 > Port (host order): 34 12 > Magic Cookie Prefix: 21 12 > Result (host order): 15 00 > X-Port (net order): 00 15 >=20 > or: >=20 > Port (host order): 34 12 > Magic Cookie Prefix: 12 21 > Result (host order): 26 33 > X-Port (net order): 33 26 >=20 > One of these is clearly wrong. I think it's the first one, but I *also*= think > that the first one is the most straightforward interpretation of the qu= oted > paragraph. >=20 > The following would seem to be a complete description of the > operation without introducing possible confusion about the difference b= etween > host and network order: >=20 > X-Port is computed by XOR'ing the mapped port with the most signific= ant 16 > bits of the magic cookie. If the IP address family is IPv4, X-Addre= ss is > computed XOR'ing the mapped IP with the magic cookie. If the IP add= ress > family is IPv6, X-Address is computed by XOR'ing the mapped IP addre= ss with > the concatenation of the magic cookie and the 96-bit transaction ID.= In all > cases, the XOR operation works on its inputs in network byte order (= that is, > the order they will be encoded in the message). >=20 > This makes it clear that the proper operation is: >=20 > Port: 12 34 > Magic Cookie Prefix: 21 12 > Result / X-Port: 33 26 It seems that you are advocating the opposite of what is traditionally do= ne on that subject: Always do all the calculations using the computer or= der and eventually convert to/from the network order when writing/reading= a packet. That basically force all little-endian computers (which is mo= st computers nowadays) to do their work in big-endian format. If there is some ambiguity in the text, I am all for fixing it, for examp= le by saying that the 16 bits of the magic cookie, the magic cookie and t= he concatenation of the magic cookie and the 96-bit transaction ID should= all be converted into host byte order before been used with the XOR oper= ation - which is done automatically when loading them in integer variable= s. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A717.3.1: >=20 >> IANA is requested to update the names for attributes 0x0002, 0x0003, >> 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from RFC 5389 >> to RFC-to-be for the following STUN methods: > ... >> 0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUEST) >=20 > The attribute 0x0003 is registered by RFC 5780, and should not be remov= ed by this document. Fixed. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =C2=A73: >=20 > This is almost, but not quite, the boilerplate defined by RFC 8174. Ple= ase > update to match the text in RFC 8174. Already fixed following a previous review. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A75: >=20 >> server to detect if the client will understand certain attributes >> that were added in this revised specification. >=20 > This is a *bit* misleading, as these attributes were actually added in = RFC 5389. > Consider: "...that were added to STUN by [RFC5389]." Applied. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A76.1: >=20 >> If the agent is sending a request, it SHOULD add a SOFTWARE attribute= >> to the request. >=20 > I believe this would benefit from a pointer to the security section; e.= g.: > "Note that the inclusion of a SOFTWARE attribute may have security > implications; see Section 15.1.2 for details." Applied. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A76.2: >=20 >> STUN may be used >> with anycast addresses, but only with UDP and in usages where >> authentication is not used. >=20 > This bit of operational advice seems out of place in the middle of an > implementation discussion, and is quite likely to be missed by its inte= nded > audience. Consider relocating it to an "Operational Considerations" sec= tion. Done. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A76.2.1: >=20 >> As with TCP, the usage of Karn's >> algorithm is RECOMMENDED [KARN87]. >=20 > This normative language means that [KARN87] needs to be a normative ref= erence. Done. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A76.2.3 says: >=20 >> Alternatively, a >> client MAY be configured with a set of IP addresses that are trusted;= >> if a certificate is received that identifies one of those IP >> addresses, the client considers the identity of the server to be >> verified. >=20 > Presumably, this means the server supplies a certificate with SubjectAl= tName > containing an iPAddress? Please add text to clarify whether that's the > intention. >=20 > If that *is* the intended meaning, then this behavior in =C2=A78.1 seem= s > unnecessarily restrictive: >=20 >> A "stuns" URI >> containing an IP address MUST be rejected, unless the domain name is >> provided by the same mechanism that provided the STUN URI, and that >> domain name can be passed to the verification code. >=20 > Presumably, this is done because certs with iPAddress-form SubjectAltNa= mes are > pretty rare (although CAB Forum baseline requirements do explicitly all= ow > their issuance) -- but if the text in =C2=A76.2.3 is based on allowing = the use of > such certs in a TURN deployment, then it seems that URI resolution shou= ld be > also. >=20 I am not sure what was the intent there, so I'll work on that later. > -----------------------------------------------------------------------= ---- >=20 > =C2=A79.1.3: >=20 >> If the MESSAGE- >> INTEGRITY-SHA256 attribute is not present, and using the same >> password, compute the value for the message integrity as described= >> in Section 14.5. >=20 > I can't figure out what is meant by "and using the same password" here.= The > structure of the sentence would imply that the subject of "using" is "a= ttribute" > (the one that is not present), but that doesn't make sense. Is it suppo= sed to > be something like this? >=20 > If the MESSAGE-INTEGRITY-SHA256 attribute is not present, compute= the > value for the message integrity as described in Section 14.5, usi= ng the > same password as would have been used for MESSAGE-INTEGRITY-SHA25= 6. Already fixed following a previous review. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A79.1.5: >=20 >> A client sending subsequent requests to the same server MUST send >> only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute >> that matches the attribute that was received in the response to the >> initial request. >=20 > How long does it continue to do so? It seems sensible to do this for th= e > length of validity of the credentials (and no longer) -- and probably e= ven > scoped to the credentials -- but the document really should call that = out > explicitly. Doing that would mean that we expect that the server could revert from st= unbis to RFC 5389 during a session or conversely can upgrade from RFC 538= 9 to stunbis during a session. I am all for upgradability, but doing wou= ld require more analysis of the protocol to be sure that it is safe to do= so (the analysis done where only assuming that the RFC level is fixed af= ter the first round). In other words, it looks like a new feature to me. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A79.2.2: >=20 >> The structure of the key when used with long-term credentials >> facilitates deployment in systems that also utilize SIP [RFC3261]. >> 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. >=20 > Suggest adding something like: "For example, this mechanism can be used= with the > authentication extensions defined in [RFC5090]." Added. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A79.2.3.2: >=20 >> Once a request/response transaction has completed successfully, the >=20 > The use of "successfully" here is kind of confusing, since the transact= ion in > question was completed with an Error Response. Suggest dropping "succes= sfully". >=20 > -----------------------------------------------------------------------= ---- Applied. >=20 > =C2=A79.2.4: >=20 >> o If the NONCE is no longer valid, the server MUST generate an error= >> response with an error code of 438 (Stale Nonce). This response >> MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and >> SHOULD NOT include the USERNAME, USERHASH attribute, The NONCE >> attribute value MUST be valid. >=20 > Nit: The comma before the final "The" should be a period. Applied. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A79.2.4: >=20 >> USERHASH attribute. The response MAY include a MESSAGE-INTEGRITY >> or MESSAGE-INTEGRITY-SHA256 attribute, using the previous password= >> to calculate it. >=20 > I think this means to say "using the previous key," right? >=20 > -----------------------------------------------------------------------= ---- Applied. >=20 > =C2=A714: >=20 >> The >> padding bits are ignored, and may be any value. >=20 > This seems to be encouraging implementors to use uninitialized memory f= or these > bits, which could be a security issue. It would be far safer to do the = more > traditional "must be set to zero on sending, must be ignored by receive= r" thing > here. Applied. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A714.5: >=20 >> Petit-Huguenin, et al. Expires September 6, 2018 [Page 40] >> >> Internet-Draft Session Traversal Utilities for NAT (STUN) March 2018 >> Similarly, when validating the MESSAGE-INTEGRITY, the length field in= >=20 > This appears to be an errant header/footer pair. Note that the > correctly-formatted footer for page 40 appears several paragraphs later= =2E >=20 Already fixed following a previous review. > -----------------------------------------------------------------------= ---- >=20 > =C2=A714.7: >=20 >> The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which >> has a generator polynomial of >> x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. >=20 > Please correct the polynomial representation: >=20 > x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5= + x^4 > + x^2 + x + 1. Applied. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A714.8: >=20 >> The reason phrase is meant for user consumption >=20 > This is a very tricky assertion to maintain, unless you want to start w= orking > with language tags and reason phrase localization. I think you're far s= afer > saying something like "The reason phrase is meant for diagnostic purpos= es." > I would not encourage implementations to just display its contents to u= sers > without any localization discussion. Applied. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A715.2.4: >=20 > It's probably worth additionally noting that this attack can be trivial= ly > launched by the STUN server itself -- so users of STUN servers should h= ave the > same level of trust in them as any other node that can insert themselve= s into > the communication flow. Done. I mostly reused the whole paragraph above. >=20 > -----------------------------------------------------------------------= ---- >=20 > =C2=A715.3: >=20 > I'm surprised that there is no plan in here for cryptoagility of the US= ERHASH > TLV. While a practical preimage attack on SHA-256 seems pretty implausi= ble > today, it would be nice to know that we have a remedy if we ever decide= that we > need to change things. >=20 >=20 Good point. I added the following paragraph at the end: Similarly if SHA256 is found to be compromised a new user-hash attribute and a new STUN Security Feature bit will be allocated in a Standard Track document. The new user-hash attribute will have its value computed using a new hash. The STUN Security Feature bit will be used to simultaneously signal to a STUN client using the Long Term Credential Mechanism that this server supports this new hash algorithm for the user-hash, and will prevent bid down attacks on the new user-hash attribute. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --JmjH6IndchCkgqBMpkRh5aqirYwtInqBR-- --WyL8e6MSsPUzAUkT5hfNEdfZRPuZT3r00 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlreYEcACgkQKcRFldZq fsQFPxAAqVKSU+eX32b14bL8TqZkQraTOb2AZuTItZk5iFP7dHxNqVp6Wj7/yJBh FUkerOXWD3EDulk6G2ADkHUTtfWDeQGzcXdqOjAH+eud+HzxK6ydsqiuYRAEa11X 9bfhSu1SH3VwzHOaPOA1KLACmjlG5xsya32lMfc6NXNm8AP66TEmUQrerB1qdfGr Wi2Zn5Fa9oBZHZokyCY2PF5TrhANZPzIYcB7H/luLj1nKjd8KZZ+Jv3R8KrL81pR fnm5PeHCSXFrT8tuctbyOS0nNpmnOZgcyhTB+LtGR4dSqqncGichqZ0zKRw07tCK gxXmDQj9gD8fhYPJYaMWBU45IsrA1LFkPjJUFPXNdvvZuc5ldif+jauOUwOAVROy n7bFsYYACQXyh1c05Wq2lxK82TMmjGzx8tmseoh/Dd9gEzGiU9iVkFpG3ABHHgfs C6DpkE7zZZKZPs4p5ue5wsxrcHQlj18uh0ApdLuvZWA0Itu3MbCzFlygBx+LBtyy Dx8lwQj2fxC4IPKDj5x1MVOIieULhNPPICHXsABRKW/f3PMULBtcM0BcAZ8Sir7X nWf1IAx2YrtakgfrMUX8vCRb67FSiNh6KojxydfAq2ZlEvu2GnqCuSC432tXOmV0 VhFJyB30URFN6ECiuzvCsBuo+bN1Lk+5tM1OepISQqbZyxOsB/I= =MdLd -----END PGP SIGNATURE----- --WyL8e6MSsPUzAUkT5hfNEdfZRPuZT3r00-- From nobody Mon Apr 23 18:39:10 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 C19A412E034 for ; Mon, 23 Apr 2018 18:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 E6ZhjVuzylCB for ; Mon, 23 Apr 2018 18:38:54 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 84A4F12E035 for ; Mon, 23 Apr 2018 18:38:52 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id Al5zfUfqYqEz4Amuxf9Ek4; Tue, 24 Apr 2018 01:38:51 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-10v.sys.comcast.net with ESMTPA id AmuwfHrR85dFNAmuwfmGCa; Tue, 24 Apr 2018 01:38:51 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w3O1cnAF008475; Mon, 23 Apr 2018 21:38:49 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w3O1cnIf008472; Mon, 23 Apr 2018 21:38:49 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Marc Petit-Huguenin Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org In-Reply-To: <0de8c1fd-ab42-6ea2-e04e-eba05f5848df@acm.org> (petithug@acm.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 23 Apr 2018 21:38:49 -0400 Message-ID: <87d0ypbcye.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAgJ5txACYqxg6PhbR83EkVrNwEcPjQngcooMsf104HwCs5S7ui/d6DsgMGTcguaLcZ+c14EPvtsmszIZFJdfR8360kJauOzi5knKBYD3Ws7HYG9x84U 5DxD0cZiQBZiM1rv5olS+HkRpLTwd3AbVlHiz+f9mleNNhE7wUQp13Joy3ZdklbxcvEHDJX99NHpU4tkp5h/HfGcRcD+FbYDH/z9bLKSy5wCmmR37nB1PSP+ Xhmtip2eyJ6UWi19T3T+7rg9kK9fIJlcN7bMVz3lYUy1cbHw0Co8ZMuaqxFl1KhWjhBz50x57GwuZAmTWjDp5HofU86yYcG1sDtekboftG4QfgTQZ/sAaUgG q8cR6qfAfEt0vKK4yER0No+nt5/Vww== Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 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, 24 Apr 2018 01:38:56 -0000 Marc Petit-Huguenin writes: > I did some research and you were right, starting from the left side is > more common. My main counter-example is in fact in STUN itself as > figure 3: > > 0 1 > 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > |M |M |M|M|M|C|M|M|M|C|M|M|M|M| > |11|10|9|8|7|1|6|5|4|0|3|2|1|0| > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ [...] That's an interesting complication. As you've noted, it's nearly universal for IETF documents to use big-endian numbering. But the above example is paradoxical, as the bits are numbered in a big-endian way across the top of the diagram, from 2 to 15, while being numbered in a littl-endian way is the boxes, from 11 to 0. I had noticed that the top numbers didn't start at 0 (so I didn't count this figure in my "8 out of 10"), but I overlooked the numbers in the boxes. Dale From nobody Sat Apr 28 14:30:15 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 0B2DC127601; Sat, 28 Apr 2018 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 vekeo0YAgAnB; Sat, 28 Apr 2018 14:30:05 -0700 (PDT) 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 7DD5112778D; Sat, 28 Apr 2018 14:30:05 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:9171:1104:b81b:2778] (unknown [IPv6:2601:648:8301:730f:9171:1104:b81b:2778]) (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 71042AE844; Sat, 28 Apr 2018 23:30:00 +0200 (CEST) To: Alexey Melnikov , The IESG Cc: tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org References: <152406896286.13830.7440801444130192741.idtracker@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: Date: Sat, 28 Apr 2018 14:29:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152406896286.13830.7440801444130192741.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qesjHgN64czY8k04CibpKdqMPpaln8h7A" Archived-At: Subject: Re: [tram] Alexey Melnikov's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) 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: Sat, 28 Apr 2018 21:30:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qesjHgN64czY8k04CibpKdqMPpaln8h7A Content-Type: multipart/mixed; boundary="QVLgvj0nMekBuk057JrbhuGbGx2Fu8Ksh"; protected-headers="v1" From: Marc Petit-Huguenin To: Alexey Melnikov , The IESG Cc: tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org Message-ID: Subject: Re: [tram] Alexey Melnikov's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152406896286.13830.7440801444130192741.idtracker@ietfa.amsl.com> In-Reply-To: <152406896286.13830.7440801444130192741.idtracker@ietfa.amsl.com> --QVLgvj0nMekBuk057JrbhuGbGx2Fu8Ksh Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Alexey, Thanks for the review, please see my responses inline. On 04/18/2018 09:29 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-tram-stunbis-16: Discuss >=20 [...] >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I would like to discuss several issues with the document (which look ea= sy to > fix to me) before recommending its approval for publication as an RFC: >=20 > 1) 14.3. USERNAME >=20 > The USERNAME attribute is used for message integrity. It identifies= > the username and password combination used in the message-integrity > check. >=20 > The value of USERNAME is a variable-length value containing the > authentication username. It MUST contain a UTF-8 [RFC3629] encoded > sequence of less than 509 bytes, and MUST have been processed using > the OpaqueString profile [RFC8265]. >=20 > I am trying to understand if there was a particular reason why you didn= 't use > UsernameCasePreserved (or its case insensitive alternative) profile her= e which > was specifically designed for usernames? No reason really, Changed to UsernameCasePreserved. >=20 > A compliant implementation MUST > be able to parse UTF-8 encoded sequence of less than 763. >=20 > I am confused by this statement: you already have 509 bytes above. > Is "no" missing above? It has been pointed out (in a review that was not sent to the mailing-lis= t) that RFC 3629 can encode characters into only up to 4 bytes. So 509 b= ytes (127 characters + the eventual 0) is the actual maximum. But RFC 53= 89 said 763 (127 characters encoded into 6 bytes each, + the eventual 0),= which, although contradicting RFC 3629, may let implementers think that = they could encode with 6 bytes. Thus I am keeping the decoding requirements to 763 bytes to be compliant = with RFC 5389, but restricting the encoding to 503 bytes to be - at last-= fully compliant with RFC 3629. So I modified the text there to: The value of USERNAME is a variable-length value containing the authentication username. It MUST contain a UTF-8 [RFC3629] encoded sequence of less than 509 bytes, and MUST have been processed using the UsernameCasePreserved profile [RFC8265]. A compliant implementation MUST be able to parse UTF-8 encoded sequence of less than 763 bytes, to be compatible with [RFC5389] that mistakenly assumed up to 6 bytes per characters encoded. >=20 > 14.4. USERHASH >=20 > The USERHASH attribute is used as a replacement for the USERNAME > attribute when username anonymity is supported. >=20 > The value of USERHASH has a fixed length of 32 bytes. The username > and the realm MUST have been processed using the OpaqueString profil= e > [RFC8265] before hashing. >=20 > As above: why didn't you use UsernameCasePreserved profile which was > specifically designed for usernames? Changed. >=20 > 2) 14.9. REALM >=20 > The REALM attribute may be present in requests and responses. It > contains text that meets the grammar for "realm-value" as described > in [RFC3261] but without the double quotes and their surrounding > whitespace. That is, it is an unquoted realm-value (and is therefor= e > a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] > encoded sequence of less than 128 characters (which can be as long a= s > 509 bytes when encoding them and a long as 763 bytes when decoding > them), >=20 > (Here and similar text in several other sections) > Can you please elaborate on how you came up with values 509 and 763? > And why you need more space for decoding than for encoding of UTF-8. See above. I put the full explanation only on its first occurrence thoug= h. >=20 > and MUST have been processed using the OpaqueString profile > [RFC8265]. >=20 > 3) 14.16. ALTERNATE-DOMAIN >=20 > The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-= 8 > [RFC3629] encoded sequence of less than 128 characters (which can be= >=20 > Ekr already pointed this out, but I want to expand on this: you need to= say > whether this allows U-label (which are UTF-8) or A-labels (which are AS= CII > only). If you only allow Punycode encoded A-labels, this field doesn't = need to > be UTF-8, it only need to be ASCII. I supposed that using Punycode ensure maximum compatibility with DNS clie= nt that may not fully support Unicode, so I chose that. The value of ALTERNATE-DOMAIN is variable length. It MUST be a valid DNS name [RFC1123] (including A-labels [RFC5890]) of 255 or less ASCII characters. >=20 > As far as I remember ASCII domain names are limited to 255 bytes. >=20 > as long as 509 bytes when encoding them and as long as 763 bytes whe= n > decoding them). Fixed. >=20 > 4) >=20 > 10. ALTERNATE-SERVER Mechanism >=20 > If the transport protocol uses TLS or DTLS, then the > client looks for an ALTERNATE-DOMAIN attribute. If the attribute is= > found, the domain MUST be used to validate the certificate using the= > recommendations in [RFC6125]. >=20 > When you reference RFC 6125 you need to provide more details: >=20 > a) Are you expecting support for DNS-ID, CN-ID or both? I assume you do= n't > support SRV-ID/URI-ID (saying so explicitly would be great too). b) Are= you > expected to allow wildcards in DNS-IDs/CN-IDs? If yes, you need to say = so. New text: [...] recommendations in [RFC6125]. The certificate MUST contain an identifier of type DNS-ID or CN-ID, eventually with wildcards, but not of type SRV-ID or URI-ID. If the attribute is not found, the [...] >=20 > There is one more reference to RFC 6125 in the document, you should mak= e a > similar change there as well. New text: [...] MUST verify the identity of the server. To do that, it follows the identification procedures defined in [RFC6125], with certificate containing an identifier of type DNS-ID or CN-ID, eventually with wildcards, but not of type SRV-ID or URI-ID. Alternatively, a client [...] >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I am agreeing with DISCUSS/comments from Adam. >=20 > Additionally, I have the following comments: >=20 > 9.2.4. Receiving a Request >=20 > o If the value of the USERNAME or USERHASH attribute is not valid, > the server MUST generate an error response with an error code of > 401 (Unauthenticated). This response MUST include a REALM value.= > It is RECOMMENDED that the REALM value be the domain name of the > provider of the STUN server. >=20 > You include this sentence here and at the beginning of this section, > but not above (in at least 2 other places) where REALM is also mentione= d? > Just mention the advice once earlier in this section? Moved to first paragraph of the section. >=20 > 14.10. NONCE >=20 > Note that this means that the NONCE attribute > will not contain actual the surrounding quote characters. >=20 > This doesn't look right. Either drop "actual" or move it after "the"? >=20 >=20 Fixed. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --QVLgvj0nMekBuk057JrbhuGbGx2Fu8Ksh-- --qesjHgN64czY8k04CibpKdqMPpaln8h7A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrk59IACgkQKcRFldZq fsRjwhAAobB0c74BBNJKexjcoFlvY9PQMU9xBXmxD8AjUrT5e4fIyhCaEZ8fpSwC c1XaWm7Ya0Ca0ml2ECmVjMe5yo7uKwyKRGcNf9HzLnpLeukdq0brcKj20L0/ik+H K5X3OBqzHQ10t9yTerWQXwNSsiI0BkhD7AfcIfl0D+UqfyIuqH2r2FGaJNfptpwz ERDWlgdQe2CLefuK8pS1q+tUGl+Vblm9GHxfnPyhTXXBi95lZFCgALW2brl4RPkI WGevfQVhVUjQzrAkhdhZOCx4RUBXNhABzvhkuftD/HhXjjtByzDJks0zoexHCjUl E4MTWsktT5ntPIbUmN1/44LhcHkeljYlE44MuDUOYYyqW2zHPkSUTEtfB1Yh/6bF Evo8ETz6DOlkRIciCRRB4bxMDwtYINKMDjGdMnJQ+ZM/xLUfVmHsQzpXx0Zd5DxI wzmEpL7fuDDc0xU5K9jPEiHeDKvAfZ/pqFytc97Gn1SV7sTh7bn5n2ULox3s5l9q 9pbmO7Hd8URliZsBE6xEeu/ENV3/wfSdPKQrMrx+icCot/GgOhU2maDeVc6MB3Z0 EoT4PWIBVn6wNzirmx8D0i+5Oin4PI2EKer6HShAHyg0TYXnxO/Ee2+uG1ibJFi/ Z897di6v5Y1nKlZaYMqGgmqa2VvUzUBig5SFBmKus5idb8TI9nY= =K5gl -----END PGP SIGNATURE----- --qesjHgN64czY8k04CibpKdqMPpaln8h7A--