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 ietf@xxxxxxxx mailing lists by 2010-04-14.
Exceptionally, comments may be sent to iesg@xxxxxxxx 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/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf