IETF Logo Mail Archive

[tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return

Simon Perreault <sperreault@jive.com> Wed, 08 April 2015 12:09 UTC

Return-Path: <sperreault@jive.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CB11B3095 for <tram@ietfa.amsl.com>; Wed, 8 Apr 2015 05:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.301
X-Spam-Level:
X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TRNFER=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 M0h-hl9cVuzd for <tram@ietfa.amsl.com>; Wed, 8 Apr 2015 05:09:03 -0700 (PDT)
Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (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 71E171B306B for <tram@ietf.org>; Wed, 8 Apr 2015 05:09:03 -0700 (PDT)
Received: by qkhg7 with SMTP id g7so82342503qkh.2 for <tram@ietf.org>; Wed, 08 Apr 2015 05:09:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4xH7A5hEmCtEFHUiIzJ9hLaEMq/vXH+LPRgQr/Bm2gQ=; b=Ejew7RPBk/n1JIcXeF+O5Zz+bqTJ7vtLx/gkaBR9bYoB2L234n29h4xUyYU47pVW5e 2TrIHLd4lYfOsHvkzbba1/eTbn/yqeA1F1eLxc3QReUFWPe+mYiHrpPveqRTW0P/9m7C 8kEipxekOP/s60PI4NMGQzXLLSxfkOTwTZvcCHlsK0Ehpnz7Kt5Nbfk6hpEy0AR1Ju7q 07TS9PjyEqE4sudtH0IL4z4lDVP8N7Ja1w6PAH3ZUw0y7kZKZ7UtQ7mOPqnPB0UqAo1I qKLqo7YVdTkDhB6iY2aXlKoDOQF3wZkTsJs6+gqYylGdzZrByVnSOUEPIvec+fk0HCTd QWsw==
X-Gm-Message-State: ALoCoQmZXg4huyLRqL+RtUgmpLDf4ed6jcWNwVW/jnS0W8alcGcCw0AGY2JwBmkRaTewtgONyES5
X-Received: by 10.140.233.203 with SMTP id e194mr30359247qhc.90.1428494942764; Wed, 08 Apr 2015 05:09:02 -0700 (PDT)
Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id 9sm7440015qgo.38.2015.04.08.05.09.00 for <tram@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 05:09:01 -0700 (PDT)
Message-ID: <55251A5B.5040909@jive.com>
Date: Wed, 08 Apr 2015 08:08:59 -0400
From: Simon Perreault <sperreault@jive.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "tram@ietf.org" <tram@ietf.org>
References: <6042868B-57EB-4C5A-B93E-C58D846E14E4@cisco.com>
In-Reply-To: <6042868B-57EB-4C5A-B93E-C58D846E14E4@cisco.com>
X-Forwarded-Message-Id: <6042868B-57EB-4C5A-B93E-C58D846E14E4@cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/f_VCBsqZpaV-7EVK9YXBBNgxBz0>
Subject: [tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 08 Apr 2015 12:09:04 -0000

TRAMsters,

I'd like to see some discussion on how this impacts the server-discovery
draft. This part in particular...

"endpoints MUST NOT implement a	configuration based on unauthenticated
network multicast (e.g. mDNS)"

...seems at odds with what was decided in Dallas (i.e., define mDNS
discovery).

Thoughts?

I see having a coherent story for return and server-discovery as
somewhat required...

Simon

-------- Message transféré --------
Sujet : Re: [rtcweb] draft-schwartz-rtcweb-return
Date : Wed, 8 Apr 2015 00:58:29 +0000
De : Cullen Jennings (fluffy) <fluffy@cisco.com>
Pour : rtcweb@ietf.org <rtcweb@ietf.org>


> On Mar 26, 2015, at 9:20 AM, Cullen Jennings <fluffy@cisco.com> wrote:
> 
> I'd like to point out that the combination of ietf-tram-turn-server-discovery and draft-schwartz-rtcweb-return allow any network you are connected to more or less MITM your media and do things like rate limit it, generate analytics on who you are talking to, force your traffic through an intermediary that is in a  different legal jurisdiction and so on. 

We discussed this after the meeting and came up with a  way to resolve
this concern. Benjamin has added some text to the -06 to that
specifically addresses this issue

http://www.ietf.org/rfcdiff?url1=draft-schwartz-rtcweb-return-05&url2=draft-schwartz-rtcweb-return-06

This completely deals with the issue I raised and with that change I
support adopting this as a WG document.

After adoption, I think the WG should consider if any text is needed
around the issue of TURN credentials. (If you run TURN with no
credentials and an attacker can spoof the IP address in UDP packets, you
can end up with the TURN servers in a nasty forwarding loop that allows
an huge amplification factor for an attacker trying do DOS the turn
servers - this is still possible with authentication but you know who to
blame. When TURN was first done with was one of the reason TURN requires
auth and STUN does not). However, I believe this issue can solved and
should not block adopting the draft. )

Cullen




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email