Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism

Iñaki Baz Castillo <ibc@aliax.net> Thu, 22 September 2011 20:55 UTC

Return-Path: <ibc@aliax.net>
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 795101F0C6C for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 13:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level:
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
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 1HxQdxJtCKGx for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 13:55:01 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E139F1F0C38 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 13:55:00 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so1005105vcb.31 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 13:57:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.175.229 with SMTP id cd5mr2438818vdc.363.1316725053066; Thu, 22 Sep 2011 13:57:33 -0700 (PDT)
Received: by 10.220.94.200 with HTTP; Thu, 22 Sep 2011 13:57:33 -0700 (PDT)
In-Reply-To: <271E29CD-D561-4E29-9E2D-DD15B9461F98@cisco.com>
References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <ED2DB00E-A64B-405F-96AC-2269258F6FFC@cisco.com> <4E799ECC.8030306@ericsson.com> <DB6B2796-9762-47CA-9A45-62476146DF04@cisco.com> <4E7B7272.7020204@alvestrand.no> <CALiegfkWv9wPj8N3FLT2UpksHARp7qdSXTJVTSEyBpL7pdujcg@mail.gmail.com> <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FBC@ESESSCMS0356.eemea.ericsson.se> <271E29CD-D561-4E29-9E2D-DD15B9461F98@cisco.com>
Date: Thu, 22 Sep 2011 22:57:33 +0200
Message-ID: <CALiegf=TS3tZz2OkKKRgUdaM-dijcz3WA-qBoiU2=bwp=2PUkw@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Cullen Jennings <fluffy@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism
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, 22 Sep 2011 20:55:01 -0000

2011/9/22 Cullen Jennings <fluffy@cisco.com>:
> I see no way of solving the security problems without having ICE or something more or less like it. Therefore, I'm working on the assumption that it will only work if the SIP side supports ICE, or is front ended by a SBC with media GW that does ICE. In the short term, there will be some devices that don't do ICE but SIP devices are increasingly having ICE added. Particularly SIP devices that are internet facing because the need for NAT traversal.
>
> I find requiring ICE to be a very unfortunate assumption to have to make - obviously it reduces the number of legacy voip devices WebRTC devices can talk to without an SBC but I don't see any way around this limitation. Allowing web browsers inside the firewall to send packets to an arbitrary address that is inside the firewall with no validation that address speaks RTP is not acceptable.

Hi Cullen, if that is not so a problem in current SIP networks (most
of the devices don't support ICE), why should it be so hard and
critical for WebRTC browsers? (sorry if I miss something).

Also there are cases in which the provider (the SIP provider) does
some rewrite in both the SDP offer and answer in order to force the
media path through a media gateway (RTP proxy). Would that be not
feasible for WebRTC clients?

Thanks a lot.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>