Re: [rtcweb] Summary of ICE discussion
<sebastien.cubaud@orange.com> Tue, 11 October 2011 08:02 UTC
Return-Path: <sebastien.cubaud@orange.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 A04C421F8CD2 for <rtcweb@ietfa.amsl.com>; Tue, 11 Oct 2011 01:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.06
X-Spam-Level:
X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 abj+3mG4Q5x7 for <rtcweb@ietfa.amsl.com>; Tue, 11 Oct 2011 01:02:38 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id E706621F8C1F for <rtcweb@ietf.org>; Tue, 11 Oct 2011 01:02:37 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 614B540035; Tue, 11 Oct 2011 10:00:51 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 47E844002D; Tue, 11 Oct 2011 10:00:51 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 10:00:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Tue, 11 Oct 2011 10:00:05 +0200
Message-ID: <E6AA070839B987489960B202AD80E18D01A178C3@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <CALiegf=Xy=vGB26euObgcsXdQPepnMEyqEwGLN+vBdneUP6aPw@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Summary of ICE discussion
Thread-Index: AcyGn/6FcwsFLHX3QXeqrlBNhu/ItgBSnkag
References: <4E8B192E.80809@ericsson.com><E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr> <CALiegf=Xy=vGB26euObgcsXdQPepnMEyqEwGLN+vBdneUP6aPw@mail.gmail.com>
From: sebastien.cubaud@orange.com
To: ibc@aliax.net
X-OriginalArrivalTime: 11 Oct 2011 08:00:06.0238 (UTC) FILETIME=[C9F717E0:01CC87EB]
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: Tue, 11 Oct 2011 08:02:38 -0000
Hi Iñaki, >ICE is clearly the best solution as it handles NAT, security (peer >verification) and allows IPv4/IPv6 transition. Of course, this solution doesn't mean to address NAT traversal issues, nor multihoming. ICE still remains the best candidate for such requirements and it is in no way my intent to question the use of ICE for RTC-Web compliant agents : my proposal's goal is only to permit the minimal interoperability costs with existing SIP endpoints whilst trying to address RTC-Web specific security challenges (i.e. media consent verification). Again, it doesn't preclude the use of ICE for media consent verification, should all endpoints support ICE. Cheers Sebastien -----Message d'origine----- De : Iñaki Baz Castillo [mailto:ibc@aliax.net] Envoyé : dimanche 9 octobre 2011 18:24 À : CUBAUD Sebastien RD-CORE-LAN Cc : magnus.westerlund@ericsson.com; rtcweb@ietf.org Objet : Re: [rtcweb] Summary of ICE discussion 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>
- Re: [rtcweb] Summary of ICE discussion Randell Jesup
- [rtcweb] Summary of ICE discussion Magnus Westerlund
- Re: [rtcweb] Summary of ICE discussion Iñaki Baz Castillo
- Re: [rtcweb] Summary of ICE discussion Randell Jesup
- Re: [rtcweb] Summary of ICE discussion Olle E. Johansson
- Re: [rtcweb] Summary of ICE discussion Eric Rescorla
- Re: [rtcweb] Summary of ICE discussion Cary Bran (cbran)
- Re: [rtcweb] Summary of ICE discussion Hadriel Kaplan
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Cullen Jennings
- Re: [rtcweb] Summary of ICE discussion Cullen Jennings
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Ravindran Parthasarathi
- Re: [rtcweb] Summary of ICE discussion Roman Shpount
- Re: [rtcweb] Summary of ICE discussion Magnus Westerlund
- Re: [rtcweb] Summary of ICE discussion Magnus Westerlund
- Re: [rtcweb] Summary of ICE discussion Harald Alvestrand
- Re: [rtcweb] Summary of ICE discussion Harald Alvestrand
- Re: [rtcweb] Summary of ICE discussion Jonathan Lennox
- Re: [rtcweb] Summary of ICE discussion Ravindran Parthasarathi
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Harald Alvestrand
- Re: [rtcweb] Summary of ICE discussion Cullen Jennings
- Re: [rtcweb] Summary of ICE discussion Paul Hoffman
- Re: [rtcweb] Summary of ICE discussion sebastien.cubaud
- Re: [rtcweb] Summary of ICE discussion Iñaki Baz Castillo
- [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re… Harald Alvestrand
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… sebastien.cubaud
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Eric Rescorla
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Iñaki Baz Castillo
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Randell Jesup
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Jonathan Rosenberg
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Randell Jesup
- Re: [rtcweb] Summary of ICE discussion sebastien.cubaud
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Iñaki Baz Castillo
- Re: [rtcweb] Summary of ICE discussion Iñaki Baz Castillo
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Tim Panton
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… sebastien.cubaud
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… sebastien.cubaud
- Re: [rtcweb] Summary of ICE discussion sebastien.cubaud