Re: Some views on Secure RTP

[Werner Dittmann <Werner.Dittmann@xxxxxxxxxxx>]

Dan Wing wrote:
> ...
>> None of these are trivially interopable across protocol 
>> boundaries because they all require changes to the 
>> signalling channel, and some of them require a PKI
>>
>> ZRTP "just works"
> 
> Yes, most of the time ZRTP does just work.  It is also available 
> as an SDK so it's easy to plug it into existing software or 
> run it underneath existing software without any software 
> modifications.  Fully agreed there.
> 
> 
> However, the reason it 'just works' is that it doesn't signal
> itself in the SIP/H.323/XMPP call signaling path.  This is not
> without problems:
> 
> Specifically, some networks have slotted schedulers -- such as 3GPP
> wireless networks and such as DOCSIS cable networks.  In those
> networks, the bandwidth needed to run a codec is carefully calculated
> based on the SDP.  When used with audio, SRTP typically adds 4 bytes
> to the length of the normal RTP payload.  This additional 4 bytes
> exceeds the bandwidth of slotted schedulers.  When this is exceeded,
> the packets are either dropped or given best-effort treatment (instead
> of being prioritized).  This causes degradation in the voice quality.
> In order to work correctly on those networks, the bandwidth of SRTP
> needs to be properly signaled, and this is done by indicating RTP/SAVP
> in the SDP.

Well, I don't see any reason why a SIP application (SIP UAC) that uses
ZRTP cannot indicate RTP/SAVP in the SDP. Or is there any reason that
prohibits that? Indicating a profile is not relevant for security. If
it is not indicated it may disturb such networks but no harm to the
security is done, AFAIK

Regards,
Werner

> 
> Guidance provided by the MMUSIC and AVT working groups is that we need
> to signal the RTP profile (RTP/SAVP), so that such slotted schedulers
> can continue to their job of prioritizing media traffic and providing
> adequate bandwidth for that media traffic.  It is for this reason that
> a subset of the MMUSIC working group have been working hard to
> complete draft-ietf-mmusic-sdp-capability-negotiation.
> 
> 
> I expect you are not using such a network with a slotted scheduler,
> and your response might be "so what".  However, the remote peer
> you are communicating with might be on such a network, and in
> order to provide proper operation that remote network needs to 
> know the bandwidth of the media.  My point is that ZRTP will not
> 'just work' on such a network unless that network assumes all
> endpoints are using ZRTP and allocates additional bandwidth for
> the length of the (unsignaled) SRTP authentication tag.
> 
> -d
> 
>