Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-03.txt

[Colin Perkins <[e-mail]>]

Hi Kevin,

Thank you so much for such a detailed review. I'm about to submit draft-ietf-avtcore-rtp-security-options-04 which incorporates your grammatical feedback, and makes numerous editorial changes to try to address your comments below.

Cheers,
Colin



On 30 Jun 2013, at 04:00, Kevin Gross wrote:
> I've now read this draft. There were too many minor grammatical issues to list individually so I edited the XML and have attached a copy.
> 
> The rest of the issues are general editorial and feedback on readability from the perspective of someone trying to learn this stuff. I hope this is useful to the authors.
> 
> General: There is no definitions section in the draft and there is a lot of security terminology in the draft. Except where noted, I was able to use Wikipedia to orient myself.
> 
> Section 2: What's the distinction, in this context, between "multicast groups" and "broadcast topologies".
> 
> Section 3, paragraph 2: Wordy
> 
> Section 3.1, paragraph 2: Wordy
> 
> Section 3.1.1, paragraph 1: Add a ref for "TLS resumption"
> 
> Section 3.1.1, paragraph 3, lines 6-8: Unclear
> 
> Section 3.1.3, first paragraph, last sentence: "SSRC uniqueness property" and its relation to this security issue requires elaboration
> 
> Section 3.1.5, second paragraph: Are any references available for proprietary solutions mentioned
> 
> Section 3.2: Where does the recommendation not to use RFC 3550 Section 9 come from?
> 
> Section 3.3, first paragraph: Unclear
> 
> Section 3.3, third paragraph: Does "central nodes" and "peers" refer to the same entities?
> 
> Section 3.4, second paragraph: Unclear
> 
> Section 3.5, second paragraph: Are any references available for proprietary solutions mentioned
> 
> Section 3.6, first paragraph: What are "RTP hint tracks"?
> 
> Section 4.1.1, Potential for other leakage: I don't understand how RTP and RTCP headers are are visible to observers when RTP and RTCP packets are wrapped in cryptographic containers. Are we talking about IPsec? Wouldn't such wrapping include these headers?
> 
> Section 4.1.3, Base level, paragraph 2, second sentence: Incomplete sentence/thought or otherwise unclear
> 
> Section 4.1.3, Using Identities, paragraph 4, first 2 sentences: Unclear
> 
> Section 4.1.4, Certificate based, lines 6-10: Confusing, run-on sentence
> 
> Section 5.2, Location disclosure: Add ref or definition for "ICE negotiation"
> 
> Section 5.2, note at end of section: Unclear
> 
> Section 7: Does a security document require a security section?
> 
> Kevin Gross
> [phone]
> Media Network Consultant
> AVA Networks - www.AVAnw.com, www.X192.org
> 
> 
> On Mon, May 6, 2013 at 3:48 AM, Magnus Westerlund <[e-mail]> wrote:
> WG,
> 
> (as individual contributor)
> 
> This update of the RTP security options has a number of improvements.
> 
> 1. It discusses known usage or inclusion in standard specs of different
> choices.
> 
> 2. It has two new examples, PSS and RTSP 2.0.
> 
> 3. A section on identity.
> 
> I think this is good enough for its purpose and would really appreciate
> some feedback on it. Both from people knowing security and people who
> don't.
> 
> Cheers
> 
> Magnus Westerlund
> 
> On 2013-05-06 11:40, [e-mail] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >  This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.
> >
> >       Title           : Options for Securing RTP Sessions
> >       Author(s)       : Magnus Westerlund
> >                           Colin Perkins
> >       Filename        : draft-ietf-avtcore-rtp-security-options-03.txt
> >       Pages           : 32
> >       Date            : 2013-05-06
> >
> > Abstract:
> >    The Real-time Transport Protocol (RTP) is used in a large number of
> >    different application domains and environments.  This heterogeneity
> >    implies that different security mechanisms are needed to provide
> >    services such as confidentiality, integrity and source authentication
> >    of RTP/RTCP packets suitable for the various environments.  The range
> >    of solutions makes it difficult for RTP-based application developers
> >    to pick the most suitable mechanism.  This document provides an
> >    overview of a number of security solutions for RTP, and gives
> >    guidance for developers on how to choose the appropriate security
> >    mechanism.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-03
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-security-options-03
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> >
> >
> 
> 
> --
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> 
> <draft-ietf-avtcore-rtp-security-options-03-kg.xml>



-- 
Colin Perkins
http://csperkins.org/