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

Simon Perreault <> Tue, 20 March 2018 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18AD8127337 for <>; Tue, 20 Mar 2018 03:08:25 -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, HTML_MESSAGE=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 ss8N1OBpplTV for <>; Tue, 20 Mar 2018 03:08:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFAE4126B6D for <>; Tue, 20 Mar 2018 03:08:20 -0700 (PDT)
Received: by with SMTP id t2-v6so1071666otj.4 for <>; Tue, 20 Mar 2018 03:08:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NdfGd6Cl9Vga7hZvWwEIYlyF5KoOW7O/k5UVNyunKXQ=; b=NQkELG9+p0neihNCTeSWWQUmJVyHV3jNvxvLIMdu5bYuIaAsnWaIFh1bukxV1uErRt LdJH2JMBaw1XAqsIsloIlMx+aP5pSR8S0dzsp2BFxPOqYuSVLUx183N9D9KyqXhB5Nhk E1j9NupZvo4axg3RUGA91C+2uuh3ba0/RTKiT3ozKB0rLsPWPFt3H/7ditvPrVrN8to5 axd6bvz3WvpMzhuKwvfUkgcMmJYukIIVi2TQ5xX4MAybOnrwTgvVLpcdCrKHA8rd/5NH mSVyUlvSTb7NIX2p1p+5Etz8SSJsvjeoF4J9qd8NtIywHKKAItuaLU2zJu0T35SorTup qUYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NdfGd6Cl9Vga7hZvWwEIYlyF5KoOW7O/k5UVNyunKXQ=; b=n12Pgz0YIJEyoZXGlLcor60ecbqKIvbqsLjD2DdSwsstBGG8JHHZMnkVcOKLRdzFgc IbmFxqeoO0IctJFvSfEAYAefB9T6PJwB8B4mxZMu4d17YjuWNLst47RpmiOKY/Zw7pq4 EkiF9iI03EY/M7gmlWIUemInvVnigVS15ozdHgOR3LMpFPd6jVJESlX47fpBMePPzWHW niWplrNKigAvHb5KiQ2lcEploo6HTcpUJgDtwS55oVd5GfQ5rkV0BbjFN+oTyW3R2AuK /8oBiAcNejh6gG3dohwfHkhf0JYtps0SMyOU8g46TRO3oFl4B+thxNhy//GJuXQl2RQb DSbA==
X-Gm-Message-State: AElRT7FStr1XDIT/MDXX+6gqUTkNoWKd1yfuI+FRsSj9DWOIkZ9BtXsI FxFYqxyP0kf9YFtlI64uPY8usU1qSKRrgOKWih68pg==
X-Google-Smtp-Source: AG47ELv9Zvjhp2dTdtl2rnHJIfJb8Es7UPGauKxWWMZazSRZkJwGaO5f7sVOv4ig1IrdIrIRaPIM01q1tsBkxdid1VM=
X-Received: by 2002:a9d:5262:: with SMTP id q34-v6mr7139059otg.67.1521540499968; Tue, 20 Mar 2018 03:08:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 20 Mar 2018 03:07:59 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Simon Perreault <>
Date: Tue, 20 Mar 2018 06:07:59 -0400
Message-ID: <>
To: Nils Ohlmeier <>
Cc: Brandon Williams <>,, Cullen Jennings <>, Eric Rescorla <>
Content-Type: multipart/alternative; boundary="0000000000000355420567d54125"
Archived-At: <>
Subject: Re: [tram] Allow TURN to forward inbound connectivity checks without permission
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Mar 2018 10:08:25 -0000

Wow, I had totally forgotten about ufrag perms!

2018-03-19 22:43 GMT+00:00 Nils Ohlmeier <>:
> 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.

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.

Also, because this is so simple (just one sentence to specify it!), and
impact potential is so great (make Brandon happy!), I wonder if we
shouldn't simply add it to TURN-bis while there's still time.

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?

Because the allocation might be paired with multiple remote candidates, I
think we'd need to always forward STUN blindly.