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(_at_)ietf(_dot_)org mailing lists by 2010-04-14. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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. 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.
- The draft claims it works with the RTP/AVP profile (although this is
misspelt AVP/RTP in section 3). This is only one of several RTP
profiles that can be used, but nothing is said about the other RTP
profiles, such as RTP/AVPF. To avoid confusion, the draft should
explicitly state which of the other RTP profiles are supported and
which are not.
- 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].
- 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.
- 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.
- The draft does not specify how traffic RTCP is secured. This might
be done using the key negotiated on the media path, or it might
require a separate ZRTP negotiation using multistream mode, but the
draft doesn't specify.
- SDES is a commonly used abbreviation in the RTP community for RTCP
Source Description packets, yet this draft uses it for other purposes.
To avoid confusion, please expand the acronym (e.g., in Section 8.2).
- 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).
- Section 10 assumes that the presence of an RTP mixer can be
determined from the signalling. This assumption is false in general,
although it's true for some SIP-initiated calls.
- The RTP header extension for ZRTP (Section 12) conflicts with the
mechanism defined in RFC 5285. At minimum, this conflict should be
documented, and it might make sense to update this draft to use the
RFC 5285 mechanism.
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf