Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

Harald Alvestrand <> Tue, 20 August 2013 10:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1593F11E8205 for <>; Tue, 20 Aug 2013 03:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.527
X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jHk54pvq0aoi for <>; Tue, 20 Aug 2013 03:43:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A605A11E8200 for <>; Tue, 20 Aug 2013 03:43:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C07C39E59F; Tue, 20 Aug 2013 12:43:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 51zl7wPBD+4j; Tue, 20 Aug 2013 12:43:13 +0200 (CEST)
Received: from (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by (Postfix) with ESMTPSA id 2E5F739E095; Tue, 20 Aug 2013 12:43:13 +0200 (CEST)
Message-ID: <>
Date: Tue, 20 Aug 2013 12:43:12 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Dan Wing <>
References: <>, <>, <> <BLU169-W11E1423497EE1A503309E793430@phx.gbl> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Aug 2013 10:43:22 -0000

On 08/20/2013 08:16 AM, Dan Wing wrote:
> On Aug 19, 2013, at 11:02 PM, Bernard Aboba <> wrote:
>> Dan Wing said:
>>> Section 2.2,
>>> "In order to deal with firewalls that block all UDP traffic, TURN over
>>> TCP MUST be supported. (QUESTION: What about ICE-TCP?)"
>>> ICE-TCP allows direct peer-to-peer communications using TCP, without a TURN server doing TCP-to-UDP interworking. I would say the industry has less experience with ICE-TCP than with ICE or with TURN-over-TCP, and because of the less experience and because ICE-TCP is arguably an *optimization*, I would say ICE-TCP is a MAY. It can't be a MUST-level requirement, at least by my threshold for MUST which is that interoperability is harmed or interoperability is impossible.
>> [BA]  While ICE-TCP will only eliminate the need for TURN over TCP in a fraction of NAT usage cases, the benefits can be substantial in the situations where it does work (and is needed).  The most popular uses of ICE-TCP so far are for things like P2P chat (e.g. MSRP), application sharing and RTP over TCP.  Given that WebRTC  could implement MSRP over the data channel, and could handle screen sharing via RTP over UDP,  the case probably needs to be made based on TURN-less conveyance of RTP over TCP (probably in a consumer scenario only, since for enterprise the TURN server would most likely be needed for firewall traversal reasons).  It's definitely not a MUST, and probably not a SHOULD either for WebRTC.
>>> Most -- but not all -- of the security obtained with TURN over TLS is achieved with TURN REST (draft-uberti-behave-turn-rest and draft-uberti-rtcweb-turn-rest). I think the working group should consider if TURN REST satisfies the requirements, or if TURN over TLS is really, really necessary.
>> [BA] Not sure I follow this.   TURN over TLS provides confidentiality for the relay addresses and also some firewall traversal benefits.  TURN REST is trying to solve a different problem entirely (e.g. misuse of TURN credentials).
> TURN REST solves misuse of credentials and significantly reduces ability to do traffic analysis of the TURN client by someone sniffing between the TURN client and TURN server (username="dwing" sent plaintext between the TURN client and TURN server).

Perhaps the -security- drafts might contain a recommendation that 
usernames for use in TURN authentications should be anonymous, 
single/limited use?

I don't want to have the RTCWEB transport stack depend on a specific 
username allocation mechanism like draft-uberti-rtcweb-turn-rest, but a 
generic recommendation to not give traceable tokens in TURN 
authentication might be a good idea.