Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need

Iñaki Baz Castillo <ibc@aliax.net> Thu, 05 April 2012 14:40 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 2785C21F85C3 for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 07:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_39=0.6, J_CHICKENPOX_44=0.6, 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 APDqCSHUU0VC for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 07:40:00 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB2921F85C0 for <rtcweb@ietf.org>; Thu, 5 Apr 2012 07:40:00 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1221159vbb.31 for <rtcweb@ietf.org>; Thu, 05 Apr 2012 07:39:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=fsYFEzQ0+yK2guzOmPpK5E9mOpSXCniVkFZtd6oDgJI=; b=d+umbB83JE9ZzUG0+Yoaska0Oe0t7ezPmZ50n0gxeSwdAF/DmP3duQK/eDHULPeQIh QzWRgGiogJQx8aAII6+Y5AOak9cuOlTT7jldQgbEORC/uzthpXNeDYmcbPefbaml8thU 1Nn5LO78fdufOlz/Gwo1ZjcZUQeSLOn8wvJHSYsxY2b9qWFEprKD4L+vlVBzm8BahB5x D/jB14gt5alXUIG/8cnVswoeDeZWDxk6HBcmEFvpBdZf1rDzw3VhXTCcKqG926F7s116 b26SNZm4ZUSoMyToiloY66FJQFtyswCLehPoRvI6ojntBHLJHmI/fTBlpAcJpKi6KZui 0CRw==
Received: by 10.52.27.1 with SMTP id p1mr1846691vdg.17.1333636799717; Thu, 05 Apr 2012 07:39:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 5 Apr 2012 07:39:39 -0700 (PDT)
In-Reply-To: <CAD5OKxu6n_yDAtsy9_pkcGyA8t15y3pY4sQoYmwoPnoL=8_=cA@mail.gmail.com>
References: <CALiegfmz6tgm9WF3KWEK5qwaBGADKFyit=egB36zkjZXNKdeHw@mail.gmail.com> <CALiegfnA8_ntYd5f935P_E6vvMwjrzt+j6UhB9vjmo6h-RzfPA@mail.gmail.com> <CAD5OKxsxrDdsoV18KB1gZSsUBPno-k2zs4E2FTUaoUBdXfh5yA@mail.gmail.com> <CAE6kErhTOFP1qna-OKRmJzM=Rssc0UEXTyDgSyKmh2AM+PuviA@mail.gmail.com> <CAD5OKxuuC1q9uCnREqi_-i0unT=6Uza+oYsCWtanbSjmSi5_DQ@mail.gmail.com> <CALiegf=qo4uWjSBx6F5PmN_vqtbqYzQ9e5igqe_YJPKj0BHQvg@mail.gmail.com> <CAD5OKxu6n_yDAtsy9_pkcGyA8t15y3pY4sQoYmwoPnoL=8_=cA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Thu, 5 Apr 2012 16:39:39 +0200
Message-ID: <CALiegfngqJLRdNPsyBtVMouD_yh+3FiUNAWBuq3vb8BbbjgTqw@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlN4Wn54bJu4j3lVWl4XL4hw0aHjTGnM9llgKs50+k7eDJ7YnU60riFwgHEnC6jocvqQuph
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need
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, 05 Apr 2012 14:40:01 -0000

2012/4/5 Roman Shpount <roman@telurix.com>:
>
> On Thu, Apr 5, 2012 at 5:04 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>> ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see:
>>
>>  http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png
>
>
> This picture is not entirely correct -- ICE Lite proxy should be on both SIP
> and Media path.

Incorrect. The proxy would communicate with the ICE-Lite server(s)
using some kind of proprietary protocol. This is already true in some
SIP proxies (SER, Kamailio, OpenSer) and media-proxies (rtpproxy,
mediaproxy, irtpproxy).


>> The problem arises when media encrypt/decrypt is required, and evenr
>> more when a key update in RTP (like the DTLS EKT update) must be
>> converted into a signaling re-INVITE by a super Signaling+Media B2BUA:
>>
>>  http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png
>>
>
> Not sure why key update needs to be converted into signaling if media is
> re-encrypted. Key updates on both sides of the proxy are independent. Such
> proxy can also change SDES-SRTP key on each re-INVITE initiated by either
> side, but apart from doing actual encryption/decryption, operation wise it
> should not be any different then ICE-Lite proxy.

Maybe.




>> That is a *very* limited scope of what WebRTC can provide. An IT
>> department should be able to deploy its own WebRTC infrastructure (a
>> Web+WebSocket server) within its "local" network, so browsers
>> accessing to such a local website share the network with SIP/XMPP
>> phones/devices/softphones.
>>
>> Please don't imagine WebRTC and SIP interop as the communication
>> between two islands ;)
>
>
> I actually do imagine WebRTC/SIP interop as two islands. If we need to proxy
> media and convert Web+WebSocket into SIP this is a definition of island
> bridge for me.

If you say that we need to "convert Web+WebSocket into SIP" then you
are absolutely wrong, even more taking into account that
"draft-ibc-sipcore-sip-websocket-01" (The WebSocket Protocol as a
Transport for SIP) is being adopted by the IETF SIPCORE Working Group
as a new SIP transport.

The slide 8 in [2] shows a *pure* SIP proxy, and not a "WebSocket to
SIP gateway". So ***NO*** island at signaling level, not at all.


[1] http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01
[2] http://sip-on-the-web.aliax.net/






>> Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent
>> mails about SDES and DTLS).
>>
>
> Once again, we still need a gateway to support ICE. If end point is adding
> ICE to interop with WebRTC, why not add DTLS-SRTP at the same time.

Building an ICE-Lite RTP/SRTP tunnel/proxy is "easy". After ICE
"handhake" the server can relay UDP packets as kernel space (conntrack
in Linux), but if you need to decrypt and encrypt you need to do that
at user space, which is much worse and requires much more CPU.



> P.S. I actually do not like DTLS-SRTP, since it does not have a large
> installed base, comes with too many features, slows down call setup, will
> requirecomplex interop and such.

> I believe we should
> design a new key exchange method, that can be mapped to SDES-SRTP via
> signaling alone,

And wouldn't that be a mechanism with "non a large installed base"?


> addresses SDES-SRTP issues (transmitting keys over clear
> channel in signaling, replay of signaling)

If HTTPS / WSS is used, there is no "clear channel". It would be easy
to mandate *all* the browser communication using TLS for the case in
which SDES-SRTP is used. That is a feasible and valid requirement
IMHO.



> without introducing all the
> problems related to DTLS-SRTP. Any number of methods using public key based
> exchange over signaling and ICE should do the trick.

So a complete new protocol. Bye any kind of interop (except if you
have the magic super B2BUA).



PS: Please consider reading Fabios's mails and reply to them. The
discussion will be more interesting is such nice explanations are not
ignored ;)


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