Re: [tram] Allow TURN to forward inbound connectivity checks without permission

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Sat, 07 April 2018 07:17 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038FC129C56 for <tram@ietfa.amsl.com>; 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 <tram@ietfa.amsl.com>; 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 <tram@ietf.org>; 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" <TirumaleswarReddy_Konda@McAfee.com>
To: Brandon Williams <brandon.williams@akamai.com>, Justin Uberti <juberti@google.com>, Simon Perreault <sperreault@jive.com>
CC: Nils Ohlmeier <nohlmeier@mozilla.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Eric Rescorla <ekr@rtfm.com>, "tram@ietf.org" <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: <BN6PR16MB14251E1A92BA6628A7256A39EAB90@BN6PR16MB1425.namprd16.prod.outlook.com>
References: <CANO7kWDd8NZ=svBONwzo6sE5YH3Y5MAdWFP2CQMiTg7M-b47AQ@mail.gmail.com> <c9ef837c-bf7c-decb-9542-8a9ddeda67fd@akamai.com> <E3AB81FC-D841-47A6-A0E2-775461779770@mozilla.com> <CANO7kWA4tmK7Di59tsjvCBoDdh-jW83FxMpqQH1-iSPGLS=mpA@mail.gmail.com> <8d57a9e5-5697-38f5-1b85-bf55930c6461@akamai.com> <BN6PR16MB142571E36A8B89196CB7B080EAAB0@BN6PR16MB1425.namprd16.prod.outlook.com> <CAOJ7v-1es3HqF4qN9Ha+v5jgGoONP0rs32vpKMJBP6j546uwqA@mail.gmail.com> <CANO7kWBS3GzjJxDt4oVhW2=Uqx8YFODY+HKEMZ+YH2cTvKa-5Q@mail.gmail.com> <CAOJ7v-1HHHTv+PuUTMFedK8XMoZCNvEtFfi0svChA_GBeFm+eQ@mail.gmail.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: <BN6PR16MB1490DC45EB63C3F8F4631BD8EAB90@BN6PR16MB1490.namprd16.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/tram/3vv2QKTFfq0hURBbdRtUILX-RHo>
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." <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: Sat, 07 Apr 2018 07:17:35 -0000

> -----Original Message-----
> From: Brandon Williams [mailto:brandon.williams@akamai.com]
> Sent: Monday, April 2, 2018 9:53 PM
> To: Justin Uberti <juberti@google.com>om>; Simon Perreault <sperreault@jive.com>
> Cc: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>om>;
> Nils Ohlmeier <nohlmeier@mozilla.com>om>; Cullen Jennings (fluffy)
> <fluffy@cisco.com>om>; Eric Rescorla <ekr@rtfm.com>om>; tram@ietf.org
> Subject: Re: [tram] Allow TURN to forward inbound connectivity checks without
> permission
> 
> 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.

Agreed, we will update the draft to explain the discussed points.

-Tiru

> 
> --Brandon
> 
> On 04/01/2018 06:09 PM, Justin Uberti wrote:
> >
> >
> > On Sun, Apr 1, 2018 at 9:56 AM Simon Perreault <sperreault@jive.com
> > <mailto:sperreault@jive.com>> wrote:
> >
> >     2018-03-31 18:50 GMT-04:00 Justin Uberti <juberti@google.com
> >     <mailto: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
> >         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).