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

[Kevin Gross <[e-mail]>]

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 <http://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
>