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

Roman Shpount <roman@telurix.com> Thu, 05 April 2012 13:53 UTC

Return-Path: <roman@telurix.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 7C24121F858F for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 06:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 5vO4+gXi4qLT for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 06:53:23 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E75221F8577 for <rtcweb@ietf.org>; Thu, 5 Apr 2012 06:53:23 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1496305pbb.31 for <rtcweb@ietf.org>; Thu, 05 Apr 2012 06:53:23 -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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=F2YWlil47VIB8pjnQ+9p7gFby0HV8l9zLyqpNoYBgBU=; b=pOWlDnmphZzcX0FAp0urkTemOgRfXVFAvjykXr3OAUDv4dtpunM51PNNEmxSyqYSjl TA4s4pn68KKiA+cb04wskoVTl/1vjpwsJa7PWS9hKPw96I5d2mXvymc+MLa6n/Wf2L0P 2t/SZfmS4xTYRnbAmpE1fO0EolD+7VTCuXMCFhL+ZQ4OXhgEKTJk60SUI7bAfEx6yZRr mnZLo6Fz/EO8QX8AIBa8zZmXFT+6RxI5ZUQOfC/S69d+NRLdAm1lcsq2AUBk4eCXvUj8 SD7KNTSekUrF7czU9bAZcVyWwsKyZhT1PZTNvzdDWePQRzYlerGWGh+l3e7DzDp+fqxv y/MQ==
Received: by 10.68.228.168 with SMTP id sj8mr3847944pbc.101.1333634003098; Thu, 05 Apr 2012 06:53:23 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id l4sm3333139pbl.27.2012.04.05.06.53.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 06:53:22 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1496270pbb.31 for <rtcweb@ietf.org>; Thu, 05 Apr 2012 06:53:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.234.228 with SMTP id uh4mr2348679pbc.78.1333634000948; Thu, 05 Apr 2012 06:53:20 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Thu, 5 Apr 2012 06:53:20 -0700 (PDT)
In-Reply-To: <CALiegf=qo4uWjSBx6F5PmN_vqtbqYzQ9e5igqe_YJPKj0BHQvg@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>
Date: Thu, 5 Apr 2012 09:53:20 -0400
Message-ID: <CAD5OKxu6n_yDAtsy9_pkcGyA8t15y3pY4sQoYmwoPnoL=8_=cA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=047d7b33da10e30f4504bceedcbc
X-Gm-Message-State: ALoCoQl0LFuG/L+6N8ycrq7ElibkX/WtVY4hrbc0ckFi5oL6I144ZTbLzT2sEI6T1ww3MNZpLemm
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 13:53:24 -0000

On Thu, Apr 5, 2012 at 5:04 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2012/4/5 Roman Shpount <roman@telurix.com>:
> > On the more serious note, very few SIP end points offer working ICE
> support.
> > So, in a large sense, interop with them is not an option.
>
> For me there is a BIG difference when a kind of B2BUA is required
> (which involves signaling "transaction"). That's the barrier IMHO.
>
> 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.

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.


> > Out of the ones
> > that do support ICE and SRTP, very few are actually connected directly
> to a
> > public internet. Most of them are connected to some sort of PBX or an IP
> PBX
> > type service. So, in reality you do not need to bridge every IP phone
> with
> > WebRTC.
>
> 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 a few PBX and hosted centrex vendors will add support for WebRTC
> > required features, we will get compatibility with existing end points.
>
> Pure SIP proxies do exist. A PBX is not always needed, so again, SIP
> world does not require to be "an island".
>

Once  again, if SIP proxy is combined with media proxy, you can bridge SIP
and WebRTC, even if DTLS-SRTP is used.


>  > To support the rest you will need to deploy some sort of gateway.
>
> 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.


> > hurdle (I am trying to be politically correct here). WebRTC enabled end
> > points, on the other hand, will offer significant benefits to traditional
> > SIP phones, since they will allow development of higher quality
> integrated
> > real time communications services. I hope this will drive a much quicker
> > standard adoption.
>
> The problem is that there is a *NEW* SRTP related spec for WebRTC:
>
>  http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-03
>
> Maybe it could also become a standard for SIP? I hope, but currently
> it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a
> island.
>
>
Same as above.

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. At the same time I do not think that
interop with legacy SDES-SRTP is a reason not to use it. I believe we
should design a new key exchange method, that can be mapped to SDES-SRTP
via signaling alone, addresses SDES-SRTP issues (transmitting keys over
clear channel in signaling, replay of signaling) 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.
_____________
Roman Shpount