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

Brandon Williams <brandon.williams@akamai.com> Mon, 02 April 2018 16:22 UTC

Return-Path: <brandon.williams@akamai.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 0F87612D7E4 for <tram@ietfa.amsl.com>; 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 <tram@ietfa.amsl.com>; 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 <tram@ietf.org>; 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 <juberti@google.com>, Simon Perreault <sperreault@jive.com>
Cc: TirumaleswarReddy_Konda@mcafee.com, Nils Ohlmeier <nohlmeier@mozilla.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Eric Rescorla <ekr@rtfm.com>, tram@ietf.org
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>
From: Brandon Williams <brandon.williams@akamai.com>
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: <CAOJ7v-1HHHTv+PuUTMFedK8XMoZCNvEtFfi0svChA_GBeFm+eQ@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/tram/MM2pSapqaDHhAzU0ERIPX3Pb3SM>
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: 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 <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).