Hiya, That one's been the topic of extended discussions between more than one generation of SEC ADs and authors/wg chairs. (History at [1].)
It has a companion document [2] that is intended to lay out the available options. (That one is less mature, or was last I looked.) I think to an extent the filename for that draft is no longer accurate, (it used to be), and its not as scary as it seems - the title is now much closer to what its about, so I hope the current content is actually ok, but comments on the content are welcome (and ought be directed to the avtcore wg [3]). To an extent, there is a bit of a mess, with the zoo of RTP profiles and applications all differing wildly to the extent that it is hard to see how one set of strong security mechanisms could be used. I haven't thought at all about whether the new threat model we're discussing here ought change our position on this one. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/history/ [2] http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-03 [3] https://datatracker.ietf.org/wg/avtcore/ On 09/19/2013 04:59 PM, Hannes Tschofenig wrote: > Hi all, > > I just ran into this document recently and I am wondering (in light of > the recent discussions) whether this is a good document to publish: > > Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single > Media Security Solution > draft-ietf-avt-srtp-not-mandatory-13.txt > > Abstract > > This memo discusses the problem of securing real-time multimedia > sessions, and explains why the Real-time Transport Protocol (RTP), > and the associated RTP control protocol (RTCP), do not mandate a > single media security mechanism. Guidelines for designers and > reviewers of future RTP extensions are provided, to ensure that > appropriate security mechanisms are mandated, and that any such > mechanisms are specified in a manner that conforms with the RTP > architecture. > > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-13 > > I am wondering whether we do ourselves a favor with trying to justify > the situation and whether there is a chance to fix the problem, at least > on the specification side. > > Ciao > Hannes > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
