Re: [rtcweb] Summary of ICE discussion

Iñaki Baz Castillo <ibc@aliax.net> Sun, 09 October 2011 16:24 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 1EE0421F8B2D for <rtcweb@ietfa.amsl.com>; Sun, 9 Oct 2011 09:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.263
X-Spam-Level:
X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 0eUmu9bfIW7X for <rtcweb@ietfa.amsl.com>; Sun, 9 Oct 2011 09:24:30 -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 6483121F8B17 for <rtcweb@ietf.org>; Sun, 9 Oct 2011 09:24:30 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so5112734vcb.31 for <rtcweb@ietf.org>; Sun, 09 Oct 2011 09:24:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.179.202 with SMTP id br10mr1124525vcb.41.1318177469492; Sun, 09 Oct 2011 09:24:29 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Sun, 9 Oct 2011 09:24:29 -0700 (PDT)
In-Reply-To: <E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr>
References: <4E8B192E.80809@ericsson.com> <E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr>
Date: Sun, 9 Oct 2011 18:24:29 +0200
Message-ID: <CALiegf=Xy=vGB26euObgcsXdQPepnMEyqEwGLN+vBdneUP6aPw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: sebastien.cubaud@orange.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Summary of ICE discussion
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: Sun, 09 Oct 2011 16:24:31 -0000

2011/10/9  <sebastien.cubaud@orange.com>;:
> This mechanism provides basic media consent verification and if it turns out
> that it provides less security properties than ICE or other drawbacks (e.g.
> increasing media session establishment delay, issues with the few initial RTP
> packets,..), it could be seen as a fallback media consent verification
> when ICE is not implemented at each end of media terminations.
>
> Looking forward to hearing feedbacks from the group on this.

Hi,

ICE is clearly the best solution as it handles NAT, security (peer
verification) and allows IPv4/IPv6 transition. SIP endpoints *MUST*
implement it or continue working in vendors wallen gardens. Bad luck
for them.

But creating a new spec (as you suggest) just to allow lazy SIP
vendors (those who has never cared about security) to interoperate
with RTCweb world instead on forcing them to implement ICE is IMHO a
very bad idea.

SIP vendors MUST do their homeworks. ICE and SRTP were initially
designed for SIP. So SIP devices MUST implement them.

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