RE: [AVT] Fwd: I-D Action:draft-zimmermann-avt-zrtp-20.txt

[Roni Even <[e-mail]>]

Hi, 
Section 4.1 points at section 8.1 of RFC 3550 that does not address SSRC
collision resolution but suggests how to lower the probability of collision.
Section 8.2 addresses the collision resolution. 
What Colin suggested is 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.
Roni Even

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Philip Zimmermann
> Sent: Thursday, June 03, 2010 7:31 AM
> To: ETF Discussion Mailing List; IETF AVT WG; Colin Perkins
> Cc: Robert Sparks
> Subject: [AVT] Fwd: I-D Action:draft-zimmermann-avt-zrtp-20.txt
> 
> 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 <[e-mail]>
> > To: IETF Discussion Mailing List <[e-mail]>
> > CC: IETF AVT WG <[e-mail]>
> >
> > On 11 May 2010, at 22:15, [e-mail] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> 
> ------------------------------------------------
> Philip R Zimmermann    [e-mail]
> (spelled with 2 n's)   http://philzimmermann.com
> tel [phone]    http://zfone.com
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt