See my comments below regarding SSRC collisions. Begin forwarded message: > -------- Original Message -------- > Subject: Re: [AVT] I-D Action:draft-zimmermann-avt-zrtp-20.txt > Date: Fri, 14 May 2010 10:23:13 +0100 > From: Colin Perkins <csp@xxxxxxxxxxxxx> > To: IETF Discussion Mailing List <ietf@xxxxxxxx> > CC: IETF AVT WG <avt@xxxxxxxx> > > On 11 May 2010, at 22:15, Internet-Drafts@xxxxxxxx wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : ZRTP: Media Path Key Agreement for Unicast Secure >> RTP >> Author(s) : P. Zimmermann, et al. >> Filename : draft-zimmermann-avt-zrtp-20.txt >> Pages : 111 >> Date : 2010-05-11 >> >> 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. The ZRTP protocol is media path keying because it is >> multiplexed on the same port as RTP and does not require support in >> the signaling protocol. ZRTP does not assume a Public Key >> Infrastructure (PKI) or require the complexity of certificates in end >> devices. For the media session, ZRTP provides confidentiality, >> protection against man-in-the-middle (MiTM) attacks, and, in cases >> where the signaling protocol provides end-to-end integrity >> protection, authentication. ZRTP can utilize a Session Description >> Protocol (SDP) attribute to provide discovery and authentication >> through the signaling channel. To provide best effort SRTP, ZRTP >> utilizes normal RTP/AVP profiles. ZRTP secures media sessions which >> include a voice media stream, and can also secure media sessions >> which do not include voice by using an optional digital signature. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-20.txt > > > This addresses some, but not all, of my comments on -17: > > - “In terms of the RTP topologies defined in [RFC5117], ZRTP is > designed for Point to Point topologies only” - if only Topo-Point-to- > Point is supported, explicitly state that by shortcut name, otherwise > also list the other topologies that are supported by shortcut name. > > - “Other [RTP] profiles MAY also be used” - which ones? Need to be > explicit, since not all conceivable RTP profiles would work with ZRTP. > > - This version states that “SSRC collisions would be disruptive to > ZRTP. This may be avoided via the mechanisms in RFC 3550, Section 8.2 > [RFC3550]”. The mechanisms in section 8.2 of RFC 3550 explain how to > resolve SSRC collisions, not how to avoid them, and say nothing about > how to avoid disruption to ZRTP. Further clarification is needed - I’d > guess that the right thing to do is to accept that SRRC collisions > are disruptive, and force a re-negotiation of the secure session. If > so, the draft needs to state this explicitly. See section 4.1, which does specify what to do if there is an SSRC collision. > > - A ZRTP Error code of 0x91 “SSRC collision” is defined, but the text > doesn’t mention how it’s used. Section 4.1 does mention how it is used. > > - The new discussion of timers for non-UDP transports in section 6 is > much improved, but could still do with giving explicit recommendations > for the lengthened timer intervals. > > - The new text regarding the ZRTP header extension is better, but > could still do with explicitly stating that not only does ZRTP not use > the RFC 5285 mechanisms, it conflicts with them. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@xxxxxxxx > https://www.ietf.org/mailman/listinfo/avt ------------------------------------------------ Philip R Zimmermann prz@xxxxxxx (spelled with 2 n's) http://philzimmermann.com tel +1 831 425-7524 http://zfone.com _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf