Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt
Karl Stahl <karl.stahl@ingate.com> Thu, 09 February 2017 12:52 UTC
Return-Path: <karl@ingate.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0FD12966C for <tram@ietfa.amsl.com>; Thu, 9 Feb 2017 04:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.009
X-Spam-Level:
X-Spam-Status: No, score=-1.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, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 01M3y9w4WzG5 for <tram@ietfa.amsl.com>; Thu, 9 Feb 2017 04:52:26 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30069.outbound.protection.outlook.com [40.107.3.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513A51294E3 for <tram@ietf.org>; Thu, 9 Feb 2017 04:52:25 -0800 (PST)
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=BXJeo64CBVUvk4a/F6dAY47Aj3b7F3ejGPOKqlrp4qw=; b=iCDpJgYrdleDkD4sBrAnHYi46EhPdmChhaij2yaY4cXKS/XHqKBRPgFi4wtyS2GRES1njleYE/N971GOpkpUpQe6TZFRNA46CV8CkN2l3Wk+nkoeeWW4LRokBeOJNGYi3xPyljSw17rNk/vd1WXBGtv/JvSDKkZ1trIqDOA+NKk=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=karl@ingate.com;
Received: from Kallei7 (90.227.80.227) by HE1PR01MB1834.eurprd01.prod.exchangelabs.com (10.165.228.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 9 Feb 2017 12:52:20 +0000
From: Karl Stahl <karl.stahl@ingate.com>
To: "'Tirumaleswar Reddy (tireddy)'" <tireddy@cisco.com>, 'Simon Perreault' <sperreault@jive.com>, 'Spencer Dawkins at IETF' <spencerdawkins.ietf@gmail.com>
References: <148427986357.3020.7793783112924549744.idtracker@ietfa.amsl.com> <a4aaffdefb794fb0a1b96f0252b862a9@XCH-RCD-017.cisco.com> <CAKKJt-fUzJJS9SXvbG2=T7PDz6nvHnhBqvHRtm-41BoGJsJC6Q@mail.gmail.com> <b139c913-a052-9397-c5df-7cd7c884cf71@jive.com> <CAKKJt-eh8ZZ=5J0KoY9zUpOhj=r9+ATSOk_hEF=G7qTt78_4-Q@mail.gmail.com> <5893bf99.0699370a.55c1f.0964SMTPIN_ADDED_BROKEN@mx.google.com> <bfd3ab0f-dbd5-2f95-1830-fc869a29d7c6@jive.com> <4547122c1f244f4db631dfda97404561@XCH-RCD-017.cisco.com> <028401d2812d$6b02c220$41084660$@stahl@ingate.com> <70420ebfeccb4c0086f946628cdc4daf@XCH-RCD-017.cisco.com> <03aa01d281d8$b4d5df80$1e819e80$@stahl@ingate.com> <c29a9ea6c4064365b05f988add8b9c63@XCH-RCD-017.cisco.com>
In-Reply-To: <c29a9ea6c4064365b05f988add8b9c63@XCH-RCD-017.cisco.com>
Date: Thu, 09 Feb 2017 13:52:15 +0100
Message-ID: <048f01d282d3$58c74390$0a55cab0$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0490_01D282DB.BA8BAB90"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHSfiNgsYWH8ggx2UOfGdVJL7afyaFdF4UAgAAf2JCAACyPAIAAotvAgAC39sCAAPfGkA==
Content-Language: sv
X-Originating-IP: [90.227.80.227]
X-ClientProxiedBy: HE1PR0101CA0013.eurprd01.prod.exchangelabs.com (10.168.141.151) To HE1PR01MB1834.eurprd01.prod.exchangelabs.com (10.165.228.24)
X-MS-Office365-Filtering-Correlation-Id: a89090f7-16f5-4326-1b18-08d450ea7c48
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR01MB1834;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR01MB1834; 3:UcQIn1p9VcdrkuDZv3wdRI7q5+p8PgPDcIICHY5Pb9e0/SDtFJZsdCJNSYP+pLRoZq/lpy0O0zmAaQiZd6ZmkX5sbmeTD1A6PyDVjrRcr9sDPDMfM1v69FqTarwK9aiesuheob7KY7qXPUELK0k7HsbAiMdrBqgghxaAbHcHsxXDdAgio5imvHrynQg7n50Vyl8tSTYddmRIEELME23ItQa/IQjrjl/e+1ylco0aJQ6uOXvTbi/KXme44hBNtKmcMXrBCfBtELY3wH41Nhd4pg==; 25:wktFeM3HDlPnSAbkmchnXH9ZFn2++960pTs8oN7rzGPxnG4VIv7OpWnQems01ZblAegUlV+gHeGWoD5fxwR+X+j0FfED4M3LtANKWVUR7OO+H9ysCRDy82D+VEpCHiehVzCbBrpowVmW52lbYun46xZ9WK40NUeJhpt4AEU0DWOjstqmqa7gaz/R+6QY1syEvFBsYpa5kI2ur5I0blVbMDm8CkW++hJdWcvvaJ/Q8sxQkjWA8xP/AdIwho4Ii5ODi+ebdv6HH1cf1C00HB6p7vnAbTqK9m2sBwtZrUtqqF9X5Fj59O9QOPR81bF4Xe8EjvO1lhq80oqJpPC6Qb3PSWgP+d3KfuoJ1y+0pRJsfp3Wsu4cIlz/pqySKKT1roWh/eYj7YwIwVG5uryY9PQmtqPLWH+Nq/Pw5D/pSm0hJmCvHbYdb9D/TJlPqD/higaJnUbHmvmBch746jjCoo+WGQ==
X-Microsoft-Exchange-Diagnostics: 1; HE1PR01MB1834; 31:N+kIuQFWkdk81Yf+LFqwpPHvFzI3vXozPenSHFN7vAbIg4sWl9tc2hcxrFghqb9q8nzAq+G+q4LAHPwbLFeDoWXcVzyBBIwcldTANXTmANcfWmf3AuU36aW1XkFuL+xdZv9cAk7slqMiMigHHp4d/B4Ycb+zz+AvoSFi7GqTadHThYYeSYDdW81zO5/tDw5sClzrLCvA+7QohMAvzjq8yajLw397K0f2ZFINKnf+e5u4XN3j2vd6RBFJZxHZM1VPGqwKG1VCs876nZ3F8mYQJ4CNJSznv75wvJizyBKRnbM=
X-Microsoft-Antispam-PRVS: <HE1PR01MB1834EA827C258758DE635C9DB1450@HE1PR01MB1834.eurprd01.prod.exchangelabs.com>
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705)(100405760836317)(95692535739014)(21748063052155);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148)(6042181); SRVR:HE1PR01MB1834; BCL:0; PCL:0; RULEID:; SRVR:HE1PR01MB1834;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR01MB1834; 4:FJXL8xE+G7F7K46LUqb4pD6u4gnoUrFahIPY8bfBod2zFAVzLGSCr14sGcANS5LjsNWy27k7al/8tJjBnM6Ul6CUANEZe0VAKkxDaSjzEZdLyIJ7trA9t2KYgJG2RT3fHQKrxOSK1O7jnHh+oG9sIM+TrCtYxtVCdQLe88UsnMPJLOr8hN79NXgXHZS4M3Z/5rRqmSAtQhyR0nsoM0dV0f+tBSLnzT9iBfdGaOgfa7oz0TsRXrVydiJrcdFsWQ2taisXrL9MAZ2fCzFtVszjmeaTCBWwZZn3Oer+spoG8aEO78UERzdZFPTrZYwwCFP6H66Oj7OgpveDGX91oUqWBoVrFLhinqEZkQh4fppTPLMbuTTyjyFc94G7tGBJL0iAJSBOMquSxKjjqETtwy/auQ2J6h8OomPx0DZ3KSi96lcjlAmdCVoo+FR6WTfiWL67FbFmQ0upCqaIocJhhVd4iY6T4ZYbRDq6OFdkw7Zk4GUpxVd8aGb56D7KVWZQXH3WGvIVlMITlZbDOUICsRXyA6ECOXbqclwawlWuIE39P+Y2tqIpFm2WDWFnZjmf0F3FC31G4yHyuUcSsRXmLmJBafhxRmsCL0MIrUuSbY5cG1oD7Dfhv8kqaWPpeBQEVSzixfaEM0qessiRK7g+JHAY242DPrbgwf9qthsH5bwHkQopvU8ACGvRyaqiFrWDIpvgdxjzWPDj/yBBARMd4ElUVu/Hy2ZE33EWoMdj4p+9IMt/aY0g7zJCaEqGXX848PnxE1uPKrl0dem3BH8JuAZvDL//qKxXThAhavDOGONF6K+Jhdia+qu0oskD6JAkSyFM
X-Forefront-PRVS: 02135EB356
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7916002)(51914003)(377454003)(24454002)(13464003)(199003)(189002)(38534002)(377424004)(2950100002)(6666003)(93886004)(606005)(230783001)(44736005)(7826002)(7736002)(14726001)(6496005)(18717965001)(6486002)(39060400001)(36756003)(92566002)(68736007)(81166006)(81156014)(50226002)(84326002)(71636004)(38730400002)(7906003)(84116002)(5890100001)(33646002)(5660300001)(105586002)(8676002)(512934002)(106356001)(106116001)(4326007)(42186005)(2906002)(96836002)(61296003)(1420700001)(76176999)(54896002)(50986999)(9686003)(790700001)(6116002)(6306002)(61793004)(236005)(25786008)(102836003)(3846002)(101416001)(97736004)(66066001)(189998001)(53946003)(16200700003)(53936002)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR01MB1834; H:Kallei7; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: ingate.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1; HE1PR01MB1834; 23:qo5mQPUv3By1EvB6RjVmLGIlBaREORzDmoD4nIcNYPIQWlPEeNQEFFj5cJaQV5sWh3tPKkuIsdpY7ccBqcg+7cvm8vTPNX8yCukSbBdrCi3Jl4fBbuFEp64nIZDRzOsFB6qPGDz7rBhN0cF97bkOjluFjTi4Y35ceAsylpG779xQByLkkEoKLVGsbHzhvyWGQ8KoAsZFPUyl/gwojMPLrVUz5y2LBZ/DR86jLBHoUaDb9MTjtfBUJ600ytnyWvDbhDZRVRi0BMYu5M7jpN3NTlTvQ2nEgq2obve7gINmrQUx73kfA0LiieXJqWgOcNAQKImCz09MRp2tfLoXBqpiRS/e3n/fprgYgMrHiH7XaXzrVGpcgxaCduop6acPxpi5zh7Quvx0IzfFFRZwoW/srABYAmiv3j/4fq/Y/yH4cHPaVvrdIHG+PouDm8rOq//AWvF5tUeLJbfcivRt+vZ5bM+m1tp0SnN9YGDZBaCCctibWDrFUBmvVXYHQn3qzqfoZh8crmEh+s+lR53i4jskygkM4HWGH7DBl1QnhR9XQc17GD/QAwzze/j185D/VYMZrIWVGQfURpXqNVNfzcl9pZbI9apWJXWNatnYcAixercjq2NauHcfTYb4ICQzugJsrMCmnvpAZYn1JMizCLFqCWpUARjoJvK61oxl4TQjwUnQM9wftd6j3IaWNCSdVLlLTHD0NOspXcNOtpmObtsRWfgBVOQVOqj18j1tcHFUNT3MvM4v3H5IRnQno/zFwzxD+uJPQy08CcbIQm3tNjrVqmuQdtvjpFQ5yO0VzHym2R+wR1uziVHrC6vtfiVZhkcgRrXSidvGz75DWQef6HvDjWo4pGcLCJ9xRkEWmNjwZP7y71CHMrsYsr1h0ZqInnjSViX+lE9+DQOTRBX2oueRp0pVzEuRM4GQW57e7N+jB4FCW1HI/39CCplI3P18DiO6Rrzhg0E6OUZLKAARImavNLxzTOQ3RF9U5RsRM+ZqXZ4kDKb9jDl+Y/V5xral2vSW77Z7f3hc1p8ihkSWOPg1GAHp2itWQupAcLgG0c2eCf1b7AhvP9nsRnf93NhnOwWGDocTmUV4hUfOjr9k2ae1M4Nt6d1/xWroPQ4JZzTpHgu68r4Xt1G5+QzQfDnTYm8bbzcjJXqDde5wBehIqAddih9kxZlYnOYYRrkVMIxHyQQoGNCEgqcRbAPVXns3UnxCmtBe+MOAKMfm9Vcw6WXavNqtWUDF+WXWcTIunaYoAvxl3iNqIH0AEfttxR5DP5mO6UzBKW41yn9TNrvj8VXGsZeasjaLHqIXRkVoMiWoERrTSl/SpPV2ny07+ensqI250GAkIUtUBJyx7aC8OUOppx32yMyVyXZTmp1Qmlw6dW01hPUQ+paHGPKe6F+7JWHHaW+soDq1DtbIK9J6hXmv5eKdVvFqupxt9NBO/BXFJOhZJwPd7xcSWB/qNMFAOyB3lqn5m4ifHNrrP/yjdKWHKKYqMFPrCUS7sYpW+LydjMClAw7EBMQA2UY3+desn9ifhrykhu2SBOmSmnq9JddA2KxUnKeTv92VVEUeKrq+IRELoJhkY5xQHCR85KnjmWKH
X-Microsoft-Exchange-Diagnostics: 1; HE1PR01MB1834; 6:L024edsXj9AD/ryL9KxQmSFsiBGW0Y0yVUPa6AejmAoH8TkN9+PUmegBGBuRbK9Fywu3DHkJ35NmfbHCIQm+5aB2y8r7Hc3ruSS2AoLioCSFHWm4WGtqxpcYefezZIVjet8BnZ+9za+Sk7faJ7XZjjDFi5AhJw3crwbhuHodc3yAvfNYj6ucpDzAHlAW4+IG/olmJer2+c1JUcd75yxZbUN/9IzNmMfRm2ZW41XaGTvqKp5x3kC/Ga3/LRX17I2caaJX98qRtJ9b2i6Oi4ceuqdnrzP/0KlFXVIw4mJH0W726+JSFt6Vo+ylepF9iOMKImzZ90EmAMf4ZjcfeSlQkKplLcqTrDLKl4H52aA1h6BqXM+Ym+qFiCdpEDDrYhRcQMsZYHh1POTiWKmH/BagBw==; 5:2avK9tDus+vlltvqDA2skgkQ+UtWV92cHdjpdQIpnGvx1FY46H1gxpfgZWAu4mRumy2KoI3mbbTxkGvTS2A1yE+uOxyCJaltydSjqlGnot8EhlPuXmpwxzpzNorRyzr25+728ln9BRcLQOjP3TqkLA==; 24:xqjlJNt9Jxvly0ckoUhAEEy7eNThUc1vtHt2f75fJEKJL7BrTrPiD5+vQ1zfa7rQku+YjuiHXHzW2gvNuBAdXEpi6Qg1+y4bAs174vehHuw=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; HE1PR01MB1834; 7:sGYa3PC3EYOoc3ILWr2j07ANUKvV/33nj4Fd/iB5sVxhUSjLYsi2S/QjhMuTLX/Qetu/Cog9XkkSewuITWim6NSBC/sKw+shN3hkgyvnrEWHQciwwnLtKJoE7wdZiTvPiSUmImTlNWxd75WydB6eGLKU2sJKYz68fQNr1O5s+SFua5SO4cEUA6mfHbilxEXIb4TgrJzhkKzpOg+lkf569L1EzvMdipHvSOfZTLISE3IiZs42MBFajYycWqgOd4+xbFn+ymSC8Ld6F4pkvNmYFC1NX9feRneJldRuiHIonGEXLC60kmwc+pxfAnaoF2bMrSArwmZc8INUq2FyVZxfCtWxHer0Y+RQR0J3Z953PJpi/cTmRgsATNacABQAiXV4a4tUixpvMGjDUqvQphAfe7IWRNqIRZOSofVl2rHFbcX7Wa8iS2SNt+1eDddcRPTP23NMP2dwy/iud6tAYMAB8/2Id15R3IsABndB4hu6dR9eNP7TbXmHeVq3FZ404eROntLsWSiN+ch3ZHrmxAVYUg==
X-OriginatorOrg: ingate.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2017 12:52:20.0829 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR01MB1834
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/EHeibjYs92U73JBMXd49gj8dttM>
Cc: tram@ietf.org
Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2017 12:52:30 -0000
Tiru, Each of your three sentences are incorrect. And, > updated in 12 version to say that (D)TLS is not mandatory to use if the network infrastructure can defend against the attacks discussed in RFC5766. --- And in addition It breaks the version -07 consensus text regarding (D)TLS usage in this situation, by introducing MUST for (D)TLS usage under 9: ...and therefore MUST NOT be used for privacy sensitive communication. ...but MUST NOT fall back without explicit administrator choice. ...but MUST NOT fall back without explicit administrator choice. and my question how the explicit administrator choice is supposed to happen in an enterprise environment or at an internet café is not answered. - I dont think Brandon or anyone asked for such impossibilities (which again seem to be created to make this specification unusable for its purpose). Please note that to my knowledge, (D)TLS usage is not mandated for any usage of TURN servers anywhere, and (again) this draft that should specify DISCOVERY cannot MANDATE USAGE. None of the discovery methods do (and cannot) use (D)TLS (that discussion is for USAGE, AFTER the DISCOVERY). The read lined -12 version is cleared from these and other flaws or mistakes. We should focus on whether the red lined version anything but improvements and adds no drawbacks over version -12 of the draft. /Karl PS: Regarding the non working anycast method, *since I highlighted in August 8, 2016, all from the Authors at the WG list is*: October 18, 2016 (from Prashanth to me and others during the discuss): We intend to add the following to explain server behavior a little better: A TURN anycast server performs checks 1 to 7 discussed in Section 6.2 of RFC5766. If all checks pass, the TURN anycast server MUST respond with a 300 (Try Alternate) error as described in [RFC5766]; November 15, 2016 (to something from Brandon): Agreed. -Tiru November 18, 2016 (to something from Brandon): +1, don't see a need for alternate mechanism. -Tiru December 22, 2016 Hi Karl, I dont understand why the mechanism where TURN server has both anycast and unicast address for re-direction wont work ? Cheers, -Tiru Now February 7, 8, 2016 See below Från: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Skickat: den 8 februari 2017 09:51 Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF' Kopia: tram@ietf.org Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt Hi Karl, We have gone over the same points over and over again and I dont see a need to document the discussion b/w you and Simon, they are only operational considerations and have no impact on the protocol. Secondly, there is no consensus on your proposed new anycast mechanism and WG members have opposed your new anycast mechanism. Regarding (D)TLS, the draft is updated in 12 version to say that (D)TLS is not mandatory to use if the network infrastructure can defend against the attacks discussed in RFC5766. This update addresses comments received from Brandon. -Tiru From: Karl Stahl [mailto:karl.stahl@ingate.com] Sent: Wednesday, February 8, 2017 12:28 PM To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; 'Simon Perreault' <sperreault@jive.com>; 'Spencer Dawkins at IETF' <spencerdawkins.ietf@gmail.com> Cc: tram@ietf.org Subject: SV: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt 1) The A)+B) method (that Simon and I discussed) is not specified in the draft -12 text and further referencing: [Tiru below]> "https://tools.ietf.org/html/rfc7094#section-3.4 also discusses similar mechanism" does not help: - It rather states issues coming from not knowing whether a server reached by anycast addressing, actually is at a unicast address or really is deployed at a anycast address (which I believe is rare). 2) Further, there are no deployment considerations for the A)+B) method in the 12 draft (compare the redlined version) It does not even discuss or list RFC7478 (Web Real-Time Communication Use Cases and Requirements) that it is supposed to meet, but which the A)+B) method is in conflict with. https://www.ietf.org/mail-archive/web/tram/current/msg02314.html and https://www.ietf.org/mail-archive/web/tram/current/msg02254.html. 3) And if the (more complex) A)+B) method would be properly defined and described in some future revision, then remains (from https://www.ietf.org/mail-archive/web/tram/current/msg02254.html): (trying to) exemplify/clarify the high level (important) points why we need/want anycast discovery by saying Binding instead of Allocate. These points are: (A) We need an anycast discovery method for auto-discovering "a TURN server" (not some special TURN server or arrangement of TURN servers "invented" for being discoverable by a certain method) (B) We need an anycast discovery method for a TURN server that is setup/installed/configured for its USAGE (which is relaying traffic) - not requiring a special network configuration just for being discoverable. (And more widely, it must be the goal of this specification to provide at least one discovery method that works for ALL network types and configurations, where a network provided TURN server may be useful - I see only anycast using Binding for querying *the TURN server's* unicast address fulfilling this.) (C) Robust (tolerant) deployment is highly preferable. (D) Ease of deployment is highly preferable. Saying Binding instead Allocate, is necessary to achieve (A) and (B), and improves (C) and (D). 4) The (D)TLS text in version -12 does not have consensus either. https://www.ietf.org/mail-archive/web/tram/current/msg02296.html and https://www.ietf.org/mail-archive/web/tram/current/msg02297.html Against my red lined (D)TLS changes, I have heard no objections (just as with the red lined anycast method). /Karl -----Ursprungligt meddelande----- Från: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Skickat: den 7 februari 2017 12:02 Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF' Kopia: tram@ietf.org Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt > -----Original Message----- > From: tram [ <mailto:tram-bounces@ietf.org> mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > Sent: Tuesday, February 7, 2017 4:02 PM > To: Tirumaleswar Reddy (tireddy) < <mailto:tireddy@cisco.com> tireddy@cisco.com>; 'Simon Perreault' > < <mailto:sperreault@jive.com> sperreault@jive.com>; 'Spencer Dawkins at IETF' > < <mailto:spencerdawkins.ietf@gmail.com> spencerdawkins.ietf@gmail.com> > Cc: <mailto:tram@ietf.org> tram@ietf.org > Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action: > draft-ietf-tram-turn-server-discovery-12.txt > > Tiru, > > That does not make the version -12 text in the draft any clearer about what > the draft's anycast method actually is. I am asking you the same question as I > asked Simon before (and only he answered): I agree with the responses Simon has already provided to all the below questions. Further, I also don't see the need to discuss the below questions in the draft because they are only operational considerations (and have no impact on the actual protocol). -Tiru > > Does the draft assume: > > (A) a TURN server listening to TWO IP addresses (that are at different > subnets) that can respond error 300 or make an allocation, distinguished by > whether the request was received on its anycast address or its unicast > address, OR > > (B) we really have TWO TURN servers to play with (the one at the anycast > address being configured to respond with the error 300, OR > > (C) the FIRST Allocate is responded to with error 300 and SUBSEQUENT > Allocates actually are making TURN allocations. > > > We cannot have an RFC, not even being clear about the method specified. > > /Karl > > > -----Ursprungligt meddelande----- > Från: Tirumaleswar Reddy (tireddy) [ <mailto:tireddy@cisco.com> mailto:tireddy@cisco.com] > Skickat: den 7 februari 2017 07:18 > Till: Simon Perreault; Karl Stahl; 'Spencer Dawkins at IETF' > Kopia: <mailto:tram@ietf.org> tram@ietf.org > Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action: > draft-ietf-tram-turn-server-discovery-12.txt > > > -----Original Message----- > > From: Simon Perreault [ <mailto:sperreault@jive.com> mailto:sperreault@jive.com] > > Sent: Friday, February 3, 2017 7:13 PM > > To: Karl Stahl < <mailto:karl.stahl@ingate.com> karl.stahl@ingate.com>; 'Spencer Dawkins at IETF' > > < <mailto:spencerdawkins.ietf@gmail.com> spencerdawkins.ietf@gmail.com> > > Cc: <mailto:tram@ietf.org> tram@ietf.org; Tirumaleswar Reddy (tireddy) < <mailto:tireddy@cisco.com> tireddy@cisco.com> > > Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D > Action: > > draft-ietf-tram-turn-server-discovery-12.txt > > > > Karl, > > > > There is no consensus in the working group behind this new anycast > > mechanism. Therefore it can not be added to the draft, and the > > mechanism defined in RFC 5766 remains. > > Yup, <https://tools.ietf.org/html/rfc7094#section-3.4> https://tools.ietf.org/html/rfc7094#section-3.4 also discusses similar > mechanism. > I don't see the need for a new anycast mechanism. > > -Tiru > > > > > Thanks, > > Simon > > > > Le 2017-02-02 à 18:23, Karl Stahl a écrit : > > > The -12 version of the draft does not include major remedies of > > > flaws that were un-addressed long before the DISCUSS, nor the latest > > > regarding the possible use of (D)TLS for auto discovered turn > > > servers provided the local or access network administrator, see > > > > > > <https://www.ietf.org/mail-archive/web/tram/current/msg02216.html> https://www.ietf.org/mail-archive/web/tram/current/msg02216.html > > > > > > > > > > > > For the latest discussed, see > > > > > > > > > > > > <https://www.ietf.org/mail-archive/web/tram/current/msg02279.html> https://www.ietf.org/mail-archive/web/tram/current/msg02279.html > > > > > >>> However, I think we need agreement on the justification for such a > > > > > >> change. > > > > > >> [Karl] Justification is in the (A), (B), (C) and (D) of > > > > > >> <https://www.ietf.org/mail-archive/web/tram/current/msg02254.html> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html > > > > > >> where saying Binding instead Allocate, is necessary to achieve (A) > > >> and > > > (B), and improves (C) and (D). > > > > > > > > > > > > Brandon> It is true that you have provided a justification for the > change. > > > > > > > > > > > > <https://www.ietf.org/mail-archive/web/tram/current/msg02296.html> https://www.ietf.org/mail-archive/web/tram/current/msg02296.html > > > > > > The (D)TLS mandating was Author's idea to throw into version -10 > > > during the discuss and remains in this version -11, breaking the > > > consensus text since version -7. > > > > > > > > > > > > <https://www.ietf.org/mail-archive/web/tram/current/msg02297.html> https://www.ietf.org/mail-archive/web/tram/current/msg02297.html > > > > > > STUN dummy authentication instead of (D)TLS as suggested by Oleg > > > Moskalenko > > > > > > > > > > > > > > > > > > I have inserted my (now edited and adopted to the latest) redlining, > > > removal of blue options etc. into the -12 draft text as attached, > > > for the author to copy from and paste. > > > > > > > > > > > > Without my red lining, current version -12 is in conflict with > > > RFC7478 (Web Real-Time Communication Use Cases and Requirements) > > > and does > > not > > > meet the need of [I-D.ietf-rtcweb-return] (Recursively Encapsulated > > > TURN) (see under redlined 7.2) > > > > > > and it does not do what was set out in the Charter and "Milestone 3: > > > TURN server auto-discovery mechanism for enterprise and ISPs" > > > > > > > > > > > > Further, the authors have in version -12 (compared to from before > > > DISCUSS) changed the text " 6. Discovery using Anycast " to: > > > > > > <https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc > > > ov ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt > > > > > > "IP anycast can also be used for TURN service discovery. A packet > > > > > > sent to an anycast address is delivered to the "topologically > > > > > > nearest" network interface with the anycast address. Using the > > > TURN > > > > > > anycast address, the only two things that need to be deployed in > > > the > > > > > > network for discovery are the two things that actually use TURN. > > > > > > > > > > > > When a client requires TURN services, it sends a TURN allocate > > > > > > request to the assigned anycast address. A TURN anycast server > > > > > > performs checks 1 to 7 discussed in Section 6.2 of [RFC5766]. If > > > all > > > > > > checks pass, the TURN anycast server MUST respond with a 300 (Try > > > > > > Alternate) error as described in Section 2.9 of [RFC5766]; The > > > > > > response contains the TURN unicast address in the > > > ALTERNATE-SERVER > > > > > > attribute. For subsequent communication with the TURN server, > > > the > > > > > > client uses the responding server's unicast address. This has to > > > be > > > > > > done because two packets addressed to an anycast address may > > > reach > > > > > > two different anycast servers. The client, thus, also needs to > > > > > > ensure that the initial request fits in a single packet. An > > > > > > implementation may choose to send out every new TURN Allocation > > > > > > request to the anycast address to discover the closest and the > > > most > > > > > > optimal unicast address for the TURN server." > > > > > > > > > > > > The highlighted "A TURN anycast server" isnothing known nor > > > described (in fact there would have to be TWO TURN servers, one > > > deployed at the anycast address and another TURN server deployed at > > > the unicast address, reacting differently to the Allocation request) > > > for this to work as clarified in WG discussions with Simon). > > > > > > > > > > > > The last sentence "An implementation may choose to send out every > > > new TURN Allocation request to the anycast address to discover the > > > closest and the most optimal unicast address for the TURN server." > > > violates security and deployment considerations (see red lined > > > considerations in attached). > > > > > > > > > > > > Further, the authors have in version -12 (compared to from before > > > DISCUSS) changed the text "7.2. Recursively Encapsulated TURN " to: > > > > > > <https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc > > > ov ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt > > > > > > "WebRTC endpoints SHOULD treat any TURN server discovered through > > the > > > > > > mechanisms described in this specification as an > > > enterprise/gateway > > > > > > or access network server, in accordance with Recursively > > > Encapsulated > > > > > > TURN [I-D.ietf-rtcweb-return]." > > > > > > > > > > > > The text is a contradiction, since the return draft deals with TURN > > > servers provided by the local or access network, not other TURN > > > servers discovered by this draft. > > > > > > > > > > > > *Current -12 draft cannot be considered to be an RFC!* > > > > > > > > > > > > I suggest the redline version of draft -12 attached is chimed into > > > now and quickly merged into a version -13, so we can avoid the > > > "Conflict Resolution and Appeals"process hinted about in > > > > > > <https://www.ietf.org/mail-archive/web/tram/current/msg02202.html> https://www.ietf.org/mail-archive/web/tram/current/msg02202.html, > > > further delaying what is needed for Internet real-time communication > > > and especially for WebRTC. > > > > > > > > > > > > /Karl > > > > > > > > > > > > *Från:*tram [ <mailto:tram-bounces@ietf.org> mailto:tram-bounces@ietf.org] *För *Spencer Dawkins at > > > IETF > > > *Skickat:* den 1 februari 2017 22:12 > > > *Till:* Simon Perreault > > > *Kopia:* <mailto:tram@ietf.org> tram@ietf.org < <mailto:tram@ietf.org> mailto:tram@ietf.org>; Tirumaleswar Reddy > > > (tireddy) > > > *Ämne:* Re: [tram] I-D Action: > > > draft-ietf-tram-turn-server-discovery-12.txt > > > > > > > > > > > > Hi, Simon, > > > > > > > > > > > > On Thu, Feb 2, 2017 at 6:00 AM, Simon Perreault <sperreault@jive.com > > > < <mailto:sperreault@jive.com> mailto:sperreault@jive.com>> wrote: > > > > > > Le 2017-02-01 à 15:37, Spencer Dawkins at IETF a écrit : > > >> Dear TRAMsters, > > >> > > >> On Fri, Jan 13, 2017 at 12:59 PM, Tirumaleswar Reddy (tireddy) > > >> <tireddy@cisco.com > > >> < <mailto:tireddy@cisco.com> mailto:tireddy@cisco.com><mailto:tireddy@cisco.com > > > < <mailto:tireddy@cisco.com> mailto:tireddy@cisco.com>>> wrote: > > >> > > >> This revision addresses comments from Brandon. > > >> > > >> -Tiru > > >> > > >> > > >> How close are we to asking Terry to clear the (last remaining) DISCUSS? > > > > > > Thanks for the reminder. > > > > > > If my co-chair and the authors have no objection, I think we're ready. > > > > > > > > > > > > I'll give this 24 hours for people to chime in, but I do want to > > > ping Terry. > > > > > > > > > > > > It's a little-appreciated thing, but AD ballot positions go away > > > when ADs go away; this document has 12 yes/no objections now, and > > > you need > > > 10 for approval, and three are from ADs who are stepping down in > > > March > > > ;-) > > > > > > > > > > > > Spencer > > > > > > > > > > > > _______________________________________________ > > > tram mailing list > > > <mailto:tram@ietf.org> tram@ietf.org > > > <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > -- > > Simon Perreault > > Director of Engineering, Platform | Jive Communications, Inc. > > <https://jive.com> https://jive.com | +1 418 478 0989 ext. 1241 | <mailto:sperreault@jive.com> sperreault@jive.com > > _______________________________________________ > tram mailing list > <mailto:tram@ietf.org> tram@ietf.org > <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram
- [tram] I-D Action: draft-ietf-tram-turn-server-di… internet-drafts
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Tirumaleswar Reddy (tireddy)
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Spencer Dawkins at IETF
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Simon Perreault
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Spencer Dawkins at IETF
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Tirumaleswar Reddy (tireddy)
- [tram] Chime in on attched redlined version-12 WA… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Simon Perreault
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl