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

[Iñaki Baz Castillo <[e-mail]>]

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

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

Too much lines if I draw such a custom protocol ;)


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

Lot's of SIP providers force the media throught a RTP proxy, which
indeed is a protocol violation since such proxies do alter the SDP
which is not allowed (theorically). But such a RTP proxy is just a UDP
tunnel so it can be done at kernel space (and it is).





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

It's possible, sure. First packets are handled in user space, and
later go to kernel space with conntrack rules. It's real and there are
two RTP proxies doing that: MediaProxy and irtpProxy.



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

If the "EKT update to SIP re-INVITE" is not required that's a good new
(at least). What I would HATE is having to deal with a signaling B2BUA
for interop with SIP.




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

I'm sure that DTLS does not solve *all* those problems.




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

I don't agree. At least ICE is specified for SIP and XMPP-Jingle. SIP
vendors are lazy since they rely of annoying SBC's that break
everything but gives them money, so they "don't need" ICE. But if
WebRTC becomes real then SIP vendors will read the ICE RFC and can
implement it.

The same is not true if a new DTLS-XXXX spec is born for WebRTC since
that would require a new standard also for SIP, XMPP and so.



> P.S. I have feeling that anything security related keeps being discussed
> here without converging anywhere.

Well, I'm learning a lot about SRTP, SDES and DTLS XD


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

So you proposed allowing plain RTP and now just a new DTLS-XXXX-SRTP
is valid for you? :)


Well, ok, IMHO there is enough debate for now. Let's wait a bit :)


-- 
Iñaki Baz Castillo
<[e-mail]>