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

Justin Uberti <juberti@google.com> Sat, 31 March 2018 22:50 UTC

Return-Path: <juberti@google.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 82D3F12420B for <tram@ietfa.amsl.com>; Sat, 31 Mar 2018 15:50:56 -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 Njr-KkltwxEM for <tram@ietfa.amsl.com>; Sat, 31 Mar 2018 15:50:54 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 CC4DF1200F1 for <tram@ietf.org>; Sat, 31 Mar 2018 15:50:53 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id s92so7131416uas.11 for <tram@ietf.org>; Sat, 31 Mar 2018 15:50:53 -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=oCFisk05R3PMGeRddoUZqOc8sdoe9kW/vUNLnCfITKY=; b=NrLY1nlURMABUt30kQ2S8GgieelI93n/FNNqkrFTyl29abSwnK4QwaVgyoK6M05RGJ jxZH24BdZIwTYdhe27olN7trOn78bCru5OKwL4g1pkGCNYJ0l4YnRJoUnU/ouXtgWy47 9X4uxQqgqrIXfcRzj8kFM/oJc+ppz3GfLt49BuMnKwQx6CYG/clHURWcq6SMgq1W1qqq dEQO4ZUmMaYD8rwOSupUSS2vxFSFA5jB4XmUc+qojjgHHZQgc+M/hdApLDbPIyPgezjd GQiHDdcdMatKBCQ3S0FK8TYnLi6RLBy1vBBF26dzL81iBwr6iWXxt4fEb1QTFqKq9Kll ABQw==
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=oCFisk05R3PMGeRddoUZqOc8sdoe9kW/vUNLnCfITKY=; b=t4UKzxNn/fkaeLQM67ZAav7mSu1YvtkZlHVPdLNJLpQYnSzwvg7KA2UrU6WrLrOSF1 Z9MEYGdbjG1QwlKtlAfaGQqTxWdmF+ssd5CBHVhrnfEjbq7bUJP2ue6Yawf+N9sA8SsG wNNAHrHGGT04ayts+mJUXdddvtuNfisEvhfjz4xGfgKb1EHvG0VSI50OQUdubSz/tj5J OhdtIFXkCY1/pYJ2axoFRzwcNrAXS8OiMR/s1FYspd1coFoxahMfFXRLmHRUpxHsOVMT 5iT+SpWpAZXyaA+QrtNEW0cH3QfwsyzpHlgEp3O3GQJK8sKZWySfajKKq94GCaeeDu5W 7/nQ==
X-Gm-Message-State: ALQs6tCC3kZ28wDObUrdfS2pd6v/RQkZYk+xouvqkzYhwxglNiBjM4CH FiiGbk3rMFaW+Bs9R9etJGwkZrxuLuyYa1hMUIvcuA==
X-Google-Smtp-Source: AIpwx4/QyXs64mc6pdy6pDi46TvqOr2m0P+TcW6l5W/Flgu4J/Ox3mTVSM3aL4YN6j2eknZAghKdCjUGNSeeUqYroQQ=
X-Received: by 10.159.41.99 with SMTP id t90mr2394186uat.127.1522536652528; Sat, 31 Mar 2018 15:50:52 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <BN6PR16MB142571E36A8B89196CB7B080EAAB0@BN6PR16MB1425.namprd16.prod.outlook.com>
From: Justin Uberti <juberti@google.com>
Date: Sat, 31 Mar 2018 22:50:41 +0000
Message-ID: <CAOJ7v-1es3HqF4qN9Ha+v5jgGoONP0rs32vpKMJBP6j546uwqA@mail.gmail.com>
To: TirumaleswarReddy_Konda@mcafee.com
Cc: Brandon Williams <brandon.williams@akamai.com>, Simon Perreault <sperreault@jive.com>, Nils Ohlmeier <nohlmeier@mozilla.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Eric Rescorla <ekr@rtfm.com>, tram@ietf.org
Content-Type: multipart/alternative; boundary="001a114dfb385570b20568bd30ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/QpPZn9fZhe44AHYMgzL_Fag041k>
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, 31 Mar 2018 22:50:56 -0000

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.

On Tue, Mar 20, 2018 at 8:09 AM Konda, Tirumaleswar Reddy <
TirumaleswarReddy_Konda@mcafee.com> wrote:

>
>
> > -----Original Message-----
> > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams
> > Sent: Tuesday, March 20, 2018 3:02 PM
> > To: Simon Perreault <sperreault@jive.com>; Nils Ohlmeier
> > <nohlmeier@mozilla.com>
> > Cc: Cullen Jennings <fluffy@cisco.com>; Eric Rescorla <ekr@rtfm.com>;
> > tram@ietf.org
> > Subject: Re: [tram] Allow TURN to forward inbound connectivity checks
> without
> > permission
> >
> > On 03/20/2018 06:07 AM, Simon Perreault wrote:
> > > Same opinion here. The point of permissions is to prevent TURN clients
> > > from being able to run generic servers. It seems like always allowing
> > > STUN packets would preserve this feature while solving the session
> > > establishment latency problem. And would be quite a bit simpler to
> > > implement than ufrag perms. Have your cake, eat it, and eat it a
> > > second time.
> >
> > If you want to prevent someone from running a server on the allocation
> you
> > can't assume that a STUN-looking packet is actually legitimate, so some
> > additional validations would be required. Perhaps packet size,
> rate-limiting, and
> > max session counts are enough.
>
> TURN server can also check for the presence of username and MI in the
> STUN packets.
>
> -Tiru
>
> >
> > ufrag permissions didn't do enough to be more meaningful there, since it
> would
> > be easy to post the ufrag somewhere public via a mechanism similar to
> dynamic
> > DNS.
> >
> > --Brandon
> >
> >
> > _______________________________________________
> > 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
>