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

Kevin Gross <kevin.gross@avanw.com> Sun, 30 June 2013 03:00 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE1021F9D88 for <avt@ietfa.amsl.com>; Sat, 29 Jun 2013 20:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.426
X-Spam-Level: *
X-Spam-Status: No, score=1.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8F35c2c+ptk for <avt@ietfa.amsl.com>; Sat, 29 Jun 2013 20:00:46 -0700 (PDT)
Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8B21F9D6C for <avt@ietf.org>; Sat, 29 Jun 2013 20:00:45 -0700 (PDT)
Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta09.emeryville.ca.mail.comcast.net with comcast id uSvy1l0011bwxycA9T0llm; Sun, 30 Jun 2013 03:00:45 +0000
Received: from mail-ob0-x22c.google.com ([IPv6:2607:f8b0:4003:c01::22c]) by omta18.emeryville.ca.mail.comcast.net with comcast id uT0i1l00R4KWrzs8eT0jC4; Sun, 30 Jun 2013 03:00:45 +0000
Received: by mail-ob0-f172.google.com with SMTP id wo10so3215978obc.3 for <avt@ietf.org>; Sat, 29 Jun 2013 20:00:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cPK9WC7fpuWPzZiMrdIOUw0Ps6Osgm1jcZ4qoA30q5Q=; b=G1V+QFGziDCQSJ8JXBlAwkL6iJ5/YBX8KNwO3WuVWagDW9ASWDXYKnD+tZ5fceYRVj opBWGhryFhVcKDJcfrvM8OHyQvk3qxmlSyyQFjCAS3UupAmp9pkwsJUj4EK6Z9qLEwrj /JvIEh3STtzCL9oJKm6yRoAu9y88SY1E4hEIMfYi+qzyDrxwLTy9B80x2JkWkW+2aSTD 1rU/TdQsjJl3RxMDVK5Sq52qAtj7ZCfmFtOdTE9kHAjC7TOIuutjo01L7FpaE1bqryyG o9EeRtyarWQiwCd6MKjnQWutrQnGaPCHKWm/2jf1DOdWBvZaq7PHtVgz2eQmPhCIQ9zV uhNg==
MIME-Version: 1.0
X-Received: by 10.182.128.42 with SMTP id nl10mr5285505obb.41.1372561242707; Sat, 29 Jun 2013 20:00:42 -0700 (PDT)
Received: by 10.182.149.98 with HTTP; Sat, 29 Jun 2013 20:00:42 -0700 (PDT)
In-Reply-To: <51877C75.8040805@ericsson.com>
References: <20130506094039.7500.34911.idtracker@ietfa.amsl.com> <51877C75.8040805@ericsson.com>
Date: Sat, 29 Jun 2013 21:00:42 -0600
Message-ID: <CALw1_Q260WdntK72VdDVbQNNqS80=1pee5ZL4VkdYSmZX=s3zQ@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, draft-ietf-avtcore-rtp-security-options@tools.ietf.org
Content-Type: multipart/mixed; boundary=e89a8ff1cc9e4dddcf04e05651a8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372561245; bh=cPK9WC7fpuWPzZiMrdIOUw0Ps6Osgm1jcZ4qoA30q5Q=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=pCwK/T9jT+wvrEkh2rjhNCYfPulNw6phGfXe/MscaWoDWfGAS26YyMm4dT/Kws2Km Z0O1y5xrxXAI1B1gb4hosdASm6jNxoMO40MDsHXcDxHq44dSzEiteW1lZyyo8ak2Ih /e4/LTX5xdKEaQeCq/LuVKj/WXV9RMCMac/n/FwYL4irtGNw4IrOZXG3Z8KhSfLIR0 4KfKduY9Bwt1lwaphzIIsUFhhAdkXJgXIET7vEAYaDYLVChstASDD8AO3uTGv1vBnA zORuF4YAQOvvtcjm3xwDlNbEwiv+MPy6Op0FfY8fYNLMbSS277W7zaK8FevvLwwhop rxj7rRAWlzmsQ==
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-03.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Jun 2013 03:00:50 -0000

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
+1-303-447-0517
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 <
magnus.westerlund@ericsson.com> 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, internet-drafts@ietf.org 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
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> >
> >
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>