Re: [rtcweb] Resolving RTP/SDES question in Paris

Randell Jesup <randell-ietf@jesup.org> Sat, 17 March 2012 06:08 UTC

Return-Path: <randell-ietf@jesup.org>
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 7D9E521F8763 for <rtcweb@ietfa.amsl.com>; Fri, 16 Mar 2012 23:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 EDYPkVD35ZUb for <rtcweb@ietfa.amsl.com>; Fri, 16 Mar 2012 23:08:04 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C080F21F86B4 for <rtcweb@ietf.org>; Fri, 16 Mar 2012 23:08:04 -0700 (PDT)
Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1S8mnw-00075K-H4; Sat, 17 Mar 2012 01:07:54 -0500
Message-ID: <4F6429A0.4000609@jesup.org>
Date: Sat, 17 Mar 2012 02:05:20 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <4F63BA4E.305@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEC15@inba-mail01.sonusnet.com>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FEC15@inba-mail01.sonusnet.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
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: Sat, 17 Mar 2012 06:08:05 -0000

On 3/17/2012 12:13 AM, Ravindran, Parthasarathi wrote:
> Randell,
>
> In my usecase, the application will not be able to access the website without VPN connection . Please explain your bid-down attack in my usecase.

It may not in your particular case.  But the application would have to 
know the connection was over VPN and somehow verify that (how?)  Careful 
about saying "the server can't be accessed unless the VPN is up" because 
traffic can be spoofed (and not just DNS traffic) if the attacker 
controls the first router/etc.

The solution has to be solid without the user having to verify things 
and such that there isn't a high likelihood of minor mistakes 
compromising the user's security.

> You can speculate that all intranet in the world shall be broken in a moment if they use HTTP but IMO, it is just speculation. IETF specification has to be generic enough to serve all the deployment rather than handling some specific mechanism or application only.

Well, no, IETF specs do not have to serve "all" deployments or 
applications.  That's why we try to agree to use-cases and have goals.  
Often trying to solve *all* variations or cases leads to a 
never-finished, too-complex design.  It can at times be better to focus 
on a few related or similar cases that we know there's a need for, and 
later specs can extend it or provide alternatives.

Of course, we try to include as wide a range of uses as possible, and so 
your use-case may be included, but I don't think we included it in our 
use-case document last fall.

-- 
Randell Jesup
randell-ietf@jesup.org