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

[Roman Shpount <[e-mail]>]

On Thu, Apr 5, 2012 at 10:39 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> 2012/4/5 Roman Shpount <[e-mail]>:
> >
> > On Thu, Apr 5, 2012 at 5:04 AM, Iñaki Baz Castillo <[e-mail]>
> 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).
>
> Internal protocols do not matter. The "super B2BUA" can be using a custom
protocol between RTP forwarder and SIP processor. Does not change the fact
that from logical point of view it is on both SIP and media path. At
minimum you are missing a custom protocol connection between ICE-Lite
gateway and SIP proxy. So, your picture is still wrong.


> >> 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/
>
> This assumes ICE support in SIP end points. If they do not support ICE you
still need a media proxy driven by SIP proxy. Not that different from
encryption.



> >> 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.
>
> You can still get STUN messages after initial handshake, so you need to
monitor/filter media. Not sure this is possible with conntrack. If you are
doing media proxy with re-encryption in the user space you can probably get
about 10GB/sec worth of throughput with the modern dual Xeon E5 server.


> > 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"?
>

I would prefer a simpler new protocol then a complex existing one with no
real user base. Something as simple as sending public key in the SDP and
sending session key in ICE handshake STUN message would be better the DTLS.
It is simple to implement, does not send keys over clear channel, and can
be mapped to SDES-SRTP using ICE-Lite proxy with no additional signaling
messages or doing re-encryption. This probably needs to be enhanced to
support public key algorithm/key length negotiation and replay protection,
but this should be trivial as well.


> > 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.
>

HTTPS/WSS is used you provide better protection, but there are still issues
with cross-site scripting, web site security etc. You did prevent some of
the attacks, but you still nowhere near being secure. Once again, if we
have a key exchnage that can be mapped to SDES-SRTP, there is no need to
compromise.

> 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).
>

I think idea of interop is gone for all practical purposes. We gave it up
when we made ICE a requirement.


> 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've read it. Nice tutorial, but does not change anything I am saying here.

P.S. I have feeling that anything security related keeps being discussed
here without converging anywhere. My proposal (DTLS-SRTP by default,
SDES-SRTP from HTTPS sessions or RTP from HTTP session if enabled) got
ignored as well. This at least inline with current HTTP(S) security model.
______________
Roman Shpount