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

Nils Ohlmeier <nohlmeier@mozilla.com> Mon, 19 March 2018 22:43 UTC

Return-Path: <nohlmeier@mozilla.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 A8778124BAC for <tram@ietfa.amsl.com>; Mon, 19 Mar 2018 15:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham 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 O_HaTzvtXSY7 for <tram@ietfa.amsl.com>; Mon, 19 Mar 2018 15:43:08 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 8F0081205F0 for <tram@ietf.org>; Mon, 19 Mar 2018 15:43:08 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id z73so15991549wrb.0 for <tram@ietf.org>; Mon, 19 Mar 2018 15:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZjUcZcgxZvUz3x0Ia2wlgCZ6eKbm7z7eJztxTouyvIE=; b=Gl6tax5cyjL0k6XxFxJST4b/7Z5+UT84eav75E2/Quig/c/U2HJIZbokqTNuGEFjlv pHr9623jdbhOzazgluyECrR+/vJ6QQFtaNF819F6jQvlM+kzBQ+G6F3wvcAGO7MYU3Os RZyya4w3Ud+D6F5pa4VuUN7RMwnodQ2sQwPmk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZjUcZcgxZvUz3x0Ia2wlgCZ6eKbm7z7eJztxTouyvIE=; b=Cd19bbOC3LcvoplENjB6tY4QrETvWcPjlZkrpCLnuvDOj7uRubG9GOogNwN31w+nJx 44AnQbYQKO7G/IfYHFv/9Towk3OpXbJWUGf9haSF0WbEUg3fY73jjUaRpfwpXXWF1Yn1 8MUDnkE943kHhO5L2x9W/GL/X5Jpm05iX4V/jQLuGUaE6N89PNF4jBlXN2xuaqSswd85 3999LgBtSF4telwMWrCUd4Xt7jrH9XxWK8MMkn//Q/S3cxQJa0C0MV0aDZnO98SBPeRr MqQamjpn4gm2kC1Mo4ddpTBG5MMz+o9JiekF/zc22Rmzf2gup8WMus1QGoKA0om05kBT Z9Bg==
X-Gm-Message-State: AElRT7GSU0/byMfO1IoCOens/vF/T+c9X2QsuRCU/8r9pDyWAR31QUcG 4qLudXC/f0iTs9lLm7gOHg/jrQ==
X-Google-Smtp-Source: AG47ELvuFlqHuOcFuRZR4Cwu3EwtpQuwtAyYve+HeBiSmCswaOoig4HvNwJOqb8/JX3CjER4mV/hNg==
X-Received: by 10.223.163.221 with SMTP id m29mr11689842wrb.4.1521499386787; Mon, 19 Mar 2018 15:43:06 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:6d39:9314:376c:ca3b? ([2001:67c:1232:144:6d39:9314:376c:ca3b]) by smtp.gmail.com with ESMTPSA id q13sm301588wrg.56.2018.03.19.15.43.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 15:43:05 -0700 (PDT)
From: Nils Ohlmeier <nohlmeier@mozilla.com>
Message-Id: <E3AB81FC-D841-47A6-A0E2-775461779770@mozilla.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_01348824-B04E-4D72-AC19-8E3004E6EE1D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 19 Mar 2018 22:43:04 +0000
In-Reply-To: <c9ef837c-bf7c-decb-9542-8a9ddeda67fd@akamai.com>
Cc: Simon Perreault <sperreault@jive.com>, tram@ietf.org, Cullen Jennings <fluffy@cisco.com>, Eric Rescorla <ekr@rtfm.com>
To: Brandon Williams <brandon.williams@akamai.com>
References: <CANO7kWDd8NZ=svBONwzo6sE5YH3Y5MAdWFP2CQMiTg7M-b47AQ@mail.gmail.com> <c9ef837c-bf7c-decb-9542-8a9ddeda67fd@akamai.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/X1QlRhlWXMgTQuboq-VObxFzACM>
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, 19 Mar 2018 22:43:12 -0000

It does indeed.

I think in general this is worth looking into.

I also like the idea of simply forwarding all binding requests to the TURN client. Because 1) it does not expose the ufrag to the network when talking to the TURN server. And 2) it’s easier for the TURN server to just check for the STUN request type and hot have to parse for the ufrag attribute as well.

One question which comes to my mind is if the TURN server at some point, e.g. after receiving the permission request, stops forwarding the binding requests blindly?

Best
  Nils Ohlmeier

> On Mar 19, 2018, at 20:50, Brandon Williams <brandon.williams@akamai.com> wrote:
> 
> The idea reminds me of the ufrag permissions draft that Justin and I put together a few years ago. It didn't generate much interest at the time, but maybe it's time to give it another look?
> 
> https://tools.ietf.org/html/draft-williams-tram-ufrag-permission-00
> 
> Not quite "forward without permission", but close.
> 
> In addition, some of the other parts of the new media stack deck (i.e. ICN and controller-based architecture) make me think of the discussions some of us have had about trying to allow TURN servers to act as a sort-of virtual mutlicast node.
> 
> --Brandon
> 
> On 03/19/2018 06:50 AM, Simon Perreault wrote:
>> Tramsters,
>> $subject is an very interesting idea from EKR presented today by Cullen in DISPATCH. Could/should we do this in TURN-bis? This could make TURN *much* more attractive for certain use cases that require fewer round trips...
>> Simon
>> _______________________________________________
>> 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