Re: [AVT] Last Call: draft-zimmermann-avt-zrtp (ZRTP: Media Path Key Agreement for Secure RTP) to Informational RFC

[Colin Perkins <[e-mail]>]

Alan,

Thanks for your response - some comments inline.
Colin

On 23 Apr 2010, at 18:15, Alan Johnston wrote:

> Colin,
>
> Thank you for your detailed review of the draft.  See my comments  
> below.
>
> - Alan -
>
> On 4/13/10 12:19 PM, Colin Perkins wrote:
>> On 17 Mar 2010, at 22:26, The IESG wrote:
>>> The IESG has received a request from an individual submitter to  
>>> consider the following document:
>>>
>>> - 'ZRTP: Media Path Key Agreement for Secure RTP '
>>>  <draft-zimmermann-avt-zrtp-17.txt> as an Informational RFC
>>>
>>> The IESG plans to make a decision in the next few weeks, and  
>>> solicits final comments on this action.  Please send substantive  
>>> comments to the [e-mail] mailing lists by 2010-04-14.  
>>> Exceptionally, comments may be sent to [e-mail] instead. In  
>>> either case, please retain the beginning of the Subject line to  
>>> allow automated sorting.
>>
>>
>> I've reviewed this draft, and have a number of comments. The main  
>> issue is the scope of the protocol: it claims to be "Media Path Key  
>> Agreement for Secure RTP", but may be better titled "Media Path Key  
>> Agreement for Unicast Voice Telephony Using Secure RTP". The  
>> majority of RTP sessions cannot be secured using ZRTP, but this  
>> draft is virtually silent on its limitations.
>
> The draft does point out that it is for securing unicast RTP only.   
> For
> example, in Section 1:
>
> "ZRTP is designed for unicast media sessions in which there is a voice
> media stream."
>
> Including unicast in the title does seem to be a reasonable thing to  
> do
> and we will do that.
>
> However, scoping it to voice telephony is not accurate.  While the  
> Short Authentication String is the preferred security mechanism, the  
> protocol also works with digital signatures and can be authenticated  
> using an integrity protected signaling channel. Neither of these  
> methods require a voice channel.
>
> Some details follow:
>>
>> - RTP is explicitly a group communication protocol, that supports a  
>> wide range of topologies [RFC 5117], and a wide range of media  
>> types. ZRTP is defined for point-to-point audio calls or group  
>> audio conferences with a centralised conference bridge, and doesn't  
>> support the full range of RTP topologies or media formats. This is  
>> probably an acceptable limitation, but needs to be much more  
>> clearly documented than in the present draft.
>
> We propose adding unicast to the title and having this as the first
> sentence of the Abstract:
>
> "  This document defines ZRTP, a protocol for media path Diffie- 
> Hellman
>   exchange to agree on a session key and parameters for establishing
>   unicast Secure Real-time Transport Protocol (SRTP) sessions for VoIP
>   applications."

That's fine, but I do think the draft should explicitly refer to RFC  
5117 and state which of the RTP topologies described therein are  
supported.

...
>> - Section 5 uses the SSRC to associate ZRTP messages with an RTP  
>> stream, but doesn't appear to consider the possibility of an SSRC  
>> collision [RFC 3550 section 8.2].
>
> Sure - we should mention that if a VoIP call is forked to two  
> endpoints, and media sessions are established with both, and they  
> both choose the same 32 bit SSRC, then ZRTP will not be able to  
> distinguish between them.

An SSRC collision is possible, if unlikely, for unicast sessions in  
the absence of forking. I believe the draft needs to explicitly  
address what should be done in the event of an SSRC collision  
(presumably you should re-negotiate the security, which should be  
acceptable since collisions are rare).

>> - RTP can run over non-UDP transports, such as TCP and DCCP.  
>> Section 6 of the draft defines retransmission timers for ZRTP that  
>> are reasonable for RTP/UDP/IP sessions, but not for RTP/TCP/IP or  
>> RTP/DCCP/IP sessions. The draft needs to discuss use of ZRTP over  
>> non-UDP transports.
>
> If the media is transported end-to-end using a reliable transport,  
> then
> clearly ZRTP retransmissions are not needed.  However, there can be
> cases involving relays where ZRTP could be sent over a reliable
> transport part of the way, and an unreliable transport the rest of the
> way.  We will add text recommending that if reliable transport is  
> used,
> then the retransmit timers should be lengthened.

It's not clear how such scenarios can be distinguished, but okay. Some  
guidance on the appropriate values for the lengthened timers would be  
helpful.

>> - Section 7.3 discusses relaying ZRTP through a PBX. There appears  
>> to be an assumption that the PBX is configured to provide point to  
>> multipoint service as an RTCP-Terminating MCU (Topo-RTCP- 
>> terminating-MCU in the terminology of RFC 5117). None of the other  
>> topologies defined in RFC 5117 are considered.
>
> I couldn't find where you got this idea from.  A PBX is not going to  
> act as an RTCP-Terminating MCU.  It will most likely act as a B2B  
> for both the signaling and media, but it will still be 1:1.  We can  
> clarify this. ZRTP does not apply to all the topologies of RFC 5117.

But, again, you need to be explicit about how the topologies you're  
describing relate to those of RFC 5117, and which of the RFC 5117  
topologies are supported.

>> - The recommendations in Section 8.3 to avoid VBR traffic with secure
>> calls are at odds with the recent discussion in the AVT working group
>> (IETF 76).
>
> Is this discussion captured in draft-perkins-avt-srtp-vbr-audio?

Yes.

-- 
Colin Perkins
http://csperkins.org/