Re: [tram] I-D Action: draft-ietf-tram-turnbis-19.txt

Dan Wing <> Wed, 10 October 2018 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42750124D68 for <>; Wed, 10 Oct 2018 11:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eAyvkG2HdaEG for <>; Wed, 10 Oct 2018 11:03:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6522A1200D7 for <>; Wed, 10 Oct 2018 11:03:12 -0700 (PDT)
Received: by with SMTP id u74-v6so4831537oia.11 for <>; Wed, 10 Oct 2018 11:03:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=hYy8YNPOmOGxcjXdAfU4nxM8Q40WMLsKXqDp56axNho=; b=iV3fCVHaXahpaaaWBMVL5Wx7F03kmBJhd9Ac+zJp5yjw5fUHfI8reAqgurA2bLad8r 91SYCYn8V/sP4eseXYItFiYC9JbSSQsbeL0JQEXqEG3TtBljP8PlhqLzjkxiwbk+FWPX 77HjCcLzU9+8/m16WgxqOzVEXPPNm6/K3rxkk++fpEbrfwrXWwqOViCq29qRv8hXDK1/ MZ9aMj6sICTfWHUZUEDVA3kTNaIip+0DQaL1NZjE3ZLuVD5xMsKNjSrNGgNYCtWqDOzE 9A8q1wgYmwFMatAMU6rfWKp5g7lS1CnahjjP1vwkHw1OfPCWHpHu0Zo2RGVR+r0AGKNy HlEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=hYy8YNPOmOGxcjXdAfU4nxM8Q40WMLsKXqDp56axNho=; b=aQppqKp8f2Dfw/acHS8OvYMD3Idd4gMDKwWIZRpsKJBa+Z/dR3AFJcfvxgMriisYli z2CPhEae2rplWX9etpKg4tfWL/zuub8RULWZCkScISbteTaXtw8emzyNR57BwdvBOchP 73XzOssGZlgqxoAt+QWFhwfQHsickUg2eOcBd/rLAyBl8Vojk+RY3MBT9I9yb+PzYOKI ZCDKNBYTnqPlib0MShvTSLR6Ajwp6NavCeDKbqNvr4mwVZM4QmwmP4tyS6QaoeRnf95k u+MpN04SPFyI3TUw1a8GChsLq5O8RoaNFIzL85gc9QCrzGgKZ9IEXibqXUwT6KrCsNEm uXBA==
X-Gm-Message-State: ABuFfojUwFNJbp2nHRwxaqHlS7FkhgueJpM5FeqKjKZBlvTps67tUT0d wF73XSrVTkSUjxpABgDLdBI=
X-Google-Smtp-Source: ACcGV61uLR7ItjauLft/Fm6F4cGnIo+afvjtNH/GcOK6BqPHOFOTaR22PgXumhSoTQltA4gHZNHFLw==
X-Received: by 2002:aca:d6cd:: with SMTP id n196-v6mr2197658oig.32.1539194591561; Wed, 10 Oct 2018 11:03:11 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id u123-v6sm7303256oie.22.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 11:03:10 -0700 (PDT)
From: Dan Wing <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <>
Date: Wed, 10 Oct 2018 11:03:08 -0700
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-19.txt
X-Mailman-Version: 2.1.29
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Oct 2018 18:03:14 -0000

Back on 13 August 2018, Jonathan Lennox <> wrote:

> I’d also like to get security review of this change, especially from the perspective of people running firewalls.
> One of the design goals of TURN originally was that it behave like an address-dependent filtering firewall / NAT — you can’t get incoming traffic from a peer you don’t already know about. This was so it can’t be used to tunnel connections to an open server behind a firewall, e.g. to allow a controller somewhere on the open Internet to contact malware running inside a corporate network. 
> Thus, network operators can be more confident about allowing TURN traffic out through their firewalls. 
> Permissionless ICE relay support breaks this guarantee, if you can tunnel your traffic to make it look like ICE connectivity checks, and I’m worried it will make operators less willing to allow TURN out of their networks. 
> Now, maybe the relevant operators are already not allowing TURN, or there are already plenty of ways to tunnel in traffic, so this isn’t a concern. But if we change this property, I’d like to make sure we’re doing so with full consciousness and deliberation. 

I was poking through STUNbis and TURNbis recently and thought of a different approach.

Prior to -19, TURN created permissions based on the remote IP address.  Could we create permissions based on the remote STUN Username?  That would avoid the "permissionless" problem, as the local peer (which created the TURN allocation) knows half the STUN connectivity check Username (the portion before the ":"), and can communicate that to the TURN server to install what we might call a "username permission".  The TURN server could allow traffic that has (1) an IP permission or (2) is STUN with a matching Username.  We should be able to piggyback that username onto the existing TURN allocation.  Finally, considering ":" is used for the local:remote STUN username, we might consider using another character (e.g., "@") as a username prefix for the TURN server to allow, so that the local client can use different STUN usernames for other purposes.