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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]