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

Jonathan Lennox <> Mon, 13 August 2018 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41214130F59 for <>; Mon, 13 Aug 2018 08:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.41
X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7bIfls7PkjIx for <>; Mon, 13 Aug 2018 08:28:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 567ED130E30 for <>; Mon, 13 Aug 2018 08:28:23 -0700 (PDT)
Received: by with SMTP id 13-v6so11188838qkl.9 for <>; Mon, 13 Aug 2018 08:28:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4sJmq1qhswWorQjM6gtj5Pl871siJyynOkrM29L4kWI=; b=IEuFCLWGLXDxahibcbQSF78gxC5pxzNSvvjcWCMY0kamEP/olBjf5WSep2FNsyuZPk LzFNG08b0vfZBKIFigGfqPKNdYJOBM8TrbRshO9BF7jDW4sBflw6iTjv/9pwmQL6ZGmw F3NuW2D3CiBCzuK+5DC0u6C4eiEnlKLMoCGj7pABl4jj8FSfZIe6d5bHLujeYP6noalt s0OKxYhKntgG92JWegPc6KOC4IN9nSjrzU7v1Tdtxb3Mpmv5bC688s3LDG11+12AupT2 O8lfdp9SKoxJO22jRpgmTRd+ZN1XRoA9l1ovw5d/O3hE8gUd/FpJIexTdC6RQjfBP3bA TO2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4sJmq1qhswWorQjM6gtj5Pl871siJyynOkrM29L4kWI=; b=A3ttv8qcGQ069LDTF5mAckyI6noyvhLkoLuGooTIGoVZHa06WNq0QhzEHeFr92bAQ5 dESpEn3ofeUf25E0SnHruhNetkXbiPO+JkVcUj39ihJnTvzxC78gTX2n1m4WyBoGrIZc yG2O2y7nbVKgc/h+S3f95AJ7SHn3XFYxJSKvOB9VaMNgIPcNwHOHuIXfxAWTuPSVkDBw KhwIQsGvOVtV9Wh1mzSaw+BzWWCv6ds39XwmEEzn1b7AOHocgqd3MmH3u0bsXVFuHHcs o9/nGkh3sPjell8EGdJsiNFy2cHSDYLLeM2I7wf2sxfGUxN3CZ1hqfm8QEyLA5K7vENO FVpg==
X-Gm-Message-State: AOUpUlFzq1VcNQaC0Q8Qd0fNrmoapCVc8HGHYOF3LyyYufONqG0hIn1j K0eMmbQLlhkcspiAqan4TneAtFSNETE=
X-Google-Smtp-Source: AA+uWPyxQ5HPXL4IbVJCENNAAgJiZ3VW8wHk/h+KEvKqmffzfgM0T8g0jUe0+VDSI+4cfiJaQuuFoQ==
X-Received: by 2002:a37:c9da:: with SMTP id m87-v6mr16250595qkl.431.1534174102357; Mon, 13 Aug 2018 08:28:22 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id p21-v6sm11900426qtb.32.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Aug 2018 08:28:21 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Lennox <>
In-Reply-To: <>
Date: Mon, 13 Aug 2018 11:28:20 -0400
Cc:, Eric Rescorla <>, Cullen Jennings <>, Nils Ohlmeier <>, Justin Uberti <>, "Ram Mohan R (rmohanr)" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Brandon Williams <>
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.27
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: Mon, 13 Aug 2018 15:28:25 -0000

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.

> On Aug 10, 2018, at 3:35 PM, Brandon Williams <> wrote:
> Hi all,
> The one remaining item that I have been hoping for before submitted
> turnbis for publication is review of permissionless ICE relay support
> from someone who intends to make use of this new feature in the
> protocol. I attempted to get commitments for review from EKR and Cullen
> in Montreal, but they were each busy enough with other things that they
> weren't prepared to make such a commitment. So, with that in mind, I
> have a couple of questions for the list.
> For those of you who have reviewed this new content (namely Nils,
> Justin, and Ram): Have any of you implemented support for this
> capability? Or do you intend to in the near future?
> For the rest of you, is there anyone who has not reviewed the changes
> yet who has implemented these changes?
> I'm mostly concerned about verifying that an implementor has looked at
> this carefully enough to be confident that it can be implemented
> effectively, especially as regards relevant security controls to protect
> the client that is behind a relay that supports this capability.
> I'll appreciate any feedback from the list about this.
> Thanks,
> --Brandon
> On 06/04/2018 02:24 AM, Konda, Tirumaleswar Reddy wrote:
>> This revision addresses comments from Justin.
>> -Tiru
>>> -----Original Message-----
>>> From: tram [] On Behalf Of internet-
>>> Sent: Monday, June 4, 2018 11:51 AM
>>> To:
>>> Cc:
>>> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-19.txt
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the TURN Revised and Modernized WG of the IETF.
>>>        Title           : Traversal Using Relays around NAT (TURN): Relay Extensions
>>> to Session Traversal Utilities for NAT (STUN)
>>>        Authors         : Tirumaleswar Reddy
>>>                          Alan Johnston
>>>                          Philip Matthews
>>>                          Jonathan Rosenberg
>>> 	Filename        : draft-ietf-tram-turnbis-19.txt
>>> 	Pages           : 84
>>> 	Date            : 2018-06-03
>>> Abstract:
>>>   If a host is located behind a NAT, then in certain situations it can
>>>   be impossible for that host to communicate directly with other hosts
>>>   (peers).  In these situations, it is necessary for the host to use
>>>   the services of an intermediate node that acts as a communication
>>>   relay.  This specification defines a protocol, called TURN (Traversal
>>>   Using Relays around NAT), that allows the host to control the
>>>   operation of the relay and to exchange packets with its peers using
>>>   the relay.  TURN differs from some other relay control protocols in
>>>   that it allows a client to communicate with multiple peers using a
>>>   single relay address.
>>>   The TURN protocol was designed to be used as part of the ICE
>>>   (Interactive Connectivity Establishment) approach to NAT traversal,
>>>   though it also can be used without ICE.
>>>   This document obsoletes RFC 5766 and RFC 6156.
>>> The IETF datatracker status page for this draft is:
>>> There are also htmlized versions available at:
>>> A diff from the previous version is available at:
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at
>>> Internet-Drafts are also available by anonymous FTP at:
>>> _______________________________________________
>>> tram mailing list
>> _______________________________________________
>> tram mailing list
> -- 
> Brandon Williams
> Platform Engineering
> Akamai Technologies Inc.
> _______________________________________________
> tram mailing list