[rtcweb] Same location media

Roman Shpount <roman@telurix.com> Thu, 20 October 2011 16:27 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FF021F8C2D for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 09:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.727
X-Spam-Level:
X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmC+HJifk-rK for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 09:27:34 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37AF521F8C1C for <rtcweb@ietf.org>; Thu, 20 Oct 2011 09:27:32 -0700 (PDT)
Received: by qadc10 with SMTP id c10so638630qad.31 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 09:27:31 -0700 (PDT)
Received: by 10.68.4.200 with SMTP id m8mr3667399pbm.50.1319128051462; Thu, 20 Oct 2011 09:27:31 -0700 (PDT)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id y4sm20449606pbe.4.2011.10.20.09.27.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 09:27:30 -0700 (PDT)
Received: by pzk34 with SMTP id 34so7729397pzk.9 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 09:27:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.17.225 with SMTP id r1mr21410121pbd.64.1319128049833; Thu, 20 Oct 2011 09:27:29 -0700 (PDT)
Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 09:27:29 -0700 (PDT)
Date: Thu, 20 Oct 2011 12:27:29 -0400
Message-ID: <CAD5OKxuJi_VS9fRc4P6GN-StWzMhMHAQ2MyO8zJVsMfEeQRftg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Content-Type: multipart/alternative; boundary="bcaec520ea85d2d5b404afbd6e72"
Cc: rtcweb@ietf.org
Subject: [rtcweb] Same location media
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2011 16:27:35 -0000

Changing the topic from "A plea for simplicity, marketability..."

On Thu, Oct 20, 2011 at 11:57 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> Also you are asuming that the media is sent to the same IP of the web
> server (in case a RTCweb scenario does not include user2user calls).
> This is a too much simplified scenario, and you miss that a DNS A
> record can point to N IP's, and you also miss the case in which the
> webserver has an IP different than the media server (regardless they
> both are located within the same provider infrastucture). The browser
> cannot determine it by itself, so security is always a need, and IMHO
> it's a bad idea to allow a very corner case in which such security
> could be relaxed.
>
>
I am not missing the DNS issues. I wanted to bring this up in my previous
email, but did not want to confuse the issue. I don't advocate for this case
at all, I just wanted to clarify that "same origin media" does not
necessarily mean two phones in the same location and means media going to
the same location as JavaScript origination.

Few additional points related to this:

1. This is what Flash is doing now for streaming media. It does not need
consent to send media to the same server that sent the flash app.

2. I am not sure we standardized that only IP addresses are allowed in media
description.DNS names might still be allowed then this issue will become the
issue of doing a literal match.

3. There is still a security issue with ICE: we validate that STUN request
can be processed, but not that the media actually should be accepted from
this application. In some sense, current Flash cross domain polices are
stricter, since they not only validate that media is acceptable at this IP
but that it is acceptable from the app served from particular server.

In general, I think this is a good thing if I can get readily available
hardware components and connect RTC clients to my existing infrastructure (I
do have an JavaScript/HTTP to SIP proxy solution already). If we are not
breaking anything by doing this, there might be some benefit for allowing
this. But on the other hand, I already got ICE/SRTP to non-ICE/RTP media
proxy as well, so if this is not supported I will not suffer much :).

_____________
Roman Shpount