[secdir] sector review of draft-ietf-rtcweb-rtp-usage-23

Chris Inacio <inacio@cert.org> Tue, 09 June 2015 15:13 UTC

Return-Path: <inacio@cert.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B09D1A8863; Tue, 9 Jun 2015 08:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.402
X-Spam-Level:
X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv6t9jYCeydU; Tue, 9 Jun 2015 08:13:38 -0700 (PDT)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78F51A884D; Tue, 9 Jun 2015 08:13:37 -0700 (PDT)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t59FDaGk015671; Tue, 9 Jun 2015 11:13:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1433862816; bh=F0VElwMGjfY2yNutL+ttkiuK2ewOJs6JkZpO4TpjWdg=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=JlDiLUpYOSxrwcdkPvUmyq9tBet2WraIjKTNwq62gqb23W/0QHV7lJWtwdwKWOKDZ zBEkmslENJcguLot1t1PE4WRVASZWVorhpa+g1JGj1ZN1Rv8Dzkx+/vbWkOuXnEpTm xrMqMhS6PPS6mxlMAk461ND+XQ2QKRGOkXQH4BTY=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t59FDYl1031631; Tue, 9 Jun 2015 11:13:34 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0210.002; Tue, 9 Jun 2015 11:13:34 -0400
From: Chris Inacio <inacio@cert.org>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" <draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org>
Thread-Topic: sector review of draft-ietf-rtcweb-rtp-usage-23
Thread-Index: AQHQosba90/jwM6QXkWTs/Q+kZ42aQ==
Date: Tue, 09 Jun 2015 15:13:33 +0000
Message-ID: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.97.138]
Content-Type: text/plain; charset="utf-8"
Content-ID: <92D96E38118CD1488DF5B81262CF98E0@sei.cmu.edu>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/-eT1T0ORLo-PFhQkbMBqO08cgkk>
Subject: [secdir] sector review of draft-ietf-rtcweb-rtp-usage-23
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2015 15:13:40 -0000


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.


BLUF:  This draft is ready to go with some NITS.


This draft is an overarching set of guidelines of the use and application of RTP and RTCP as it applies to WebRTC and the related W3C API.  The W3C API is not described in this document, but references to functionality requirements for the API are made.

This draft is extremely well written.  At the same time, however, it reads like an encyclopedia of references and requirements across 35 different normative other referenced drafts.  Correspondingly, I did NOT read through all of the referenced drafts, nor did I believe that it was necessary in this case to do so.

The security considerations section was comprehensive and security impacts were taken into account throughout this draft.  I have two small NIT’s about the security section that I would like improved, and I feel these are rather small:  First, in the paragraph in the security section that starts “RTCP packets convey a Canonical Name…”  the authors state that the CNAME generation algorithm in described in section 4.9 – it isn’t, section 4.9 references RFC7022 for the generation algorithm.  Second, the last paragraph on page 39, starting with “Providing source authentication in multi-party…” ends the page with a large security warning.   Please include a reference in that paragraph in the security considerations and possibly to the appropriate draft/RFC which discusses that issue in some more depth.


general NITS:

I believe there are multiple versions of “end point” used in the document End Point, end-point, etc.  Those should be harmonized.


page 4:

Section 2 Rationale

“This builds on the past 20 years development of RTP to mandate the use of extensions that have shown widespread utility” 

can this be reworded to “This builds on the past 20 years of RTP development to mandate the use of extensions that have shown widespread utility.”


page 6:

“This specification requires the usage of a single CNAME when sending RTP Packet Streams…”   should the “require” be “REQUIRE”?

page 7:

"This to ensure robust handling of future extensions…” to “This is to ensure…”

page 14:

In reference to the paragraph that starts with “While the use of IP multicast...”.  There is no MAY/SHOULD/SHALL/REQUIRE etc. in the paragraph, but the last sentence does seem to imply an implementation requirement.  Was that intentional?

page 16:

“This can be various reasons for this:…”  to “There can be various reasons for this:…”

page 20:

“heterogeneous network environments using a variety set of link technologies…” get rid of “set”.

page 23:

“…supported by the RTCP Extended Reports (XR) framework [RFC3611][RFC6792].”   RFC3611 seems to be a full fledged reference while RFC6792 seems to just be text of “[RFC6792]”.

page 25:

First paragraph of section 11 defines a number of WebRTC API terms, PLEASE move those (far) forward in the document.
“The MediaStreamTracks within a MediaStream need to be possible to play out synchronized.”  rewrite to “The MediaStreamTracks within a MediaStream may need to be synchronized during play back.”  or something similar.

page 26:

“force an end-point to to disrupt”  only one “to”.

“This is motivating the discussion in Section 4.9”, (yes, now I’m really getting picky,) but the discussion was already motivated.  :)

page 27:

“Optimizations of this method is clearly possible and …”  “is” -> “are”

“receiving multiple MediaStreamTracks, where each of different MediaStreamTracks (and …” to “ … where each of *the* different MediaStreamTracks … “

“This later is relevant to handle some cases of legacy interop.” to “The later is relevant … legacy interoperability.”

page 28:

“. . . Endpoints can configure and use RTP sessions is outlined.”  change “is” to “are”

“ . . . it is common to use one RTP session for each type of media sources (e.g. . . .”  change “sources” to “source”

page 31:

“To maintain a coherent mapping between the relation between RTP sessions and RTCPeerConnection objects it is …”  rewrite to maybe

“To maintain a coherent mapping between the relationship of RTP sessions and RTCPeerConnection objects it is ….”

page 32:

“This scenario also results in that an end-point’s feedback or requests goes to the mixer…”  change “goes” to “go”.

“necessarily be explicitly visible any RTP and RTCP traffic …” to “necessarily be explicitly visible to any RTP and RTCP traffic”.

page 38:

“combing” to “combining”



--
Chris Inacio
inacio@cert.org