[secdir] SecDir review of draft-ietf-avtcore-rfc5285-bis-09

"Xialiang (Frank)" <frank.xialiang@huawei.com> Tue, 18 April 2017 03:24 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3FF126CF6; Mon, 17 Apr 2017 20:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jnip28kc0wlE; Mon, 17 Apr 2017 20:24:37 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2157D126B72; Mon, 17 Apr 2017 20:24:35 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLF11055; Tue, 18 Apr 2017 03:24:33 +0000 (GMT)
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 18 Apr 2017 04:24:32 +0100
Received: from DGGEML502-MBS.china.huawei.com ([169.254.3.93]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0301.000; Tue, 18 Apr 2017 11:24:28 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-avtcore-rfc5285-bis@ietf.org" <draft-ietf-avtcore-rfc5285-bis@ietf.org>
Thread-Topic: SecDir review of draft-ietf-avtcore-rfc5285-bis-09
Thread-Index: AdK380Ap/PwmSJJsR8uigrJB3Hee4Q==
Date: Tue, 18 Apr 2017 03:24:28 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12BAC050F@DGGEML502-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.159.76]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BAC050FDGGEML502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58F586F2.0038, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.93, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8d7ba681b7979e5a8194a57c3020ab2e
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/f8u8KB1Wk7LHJrJRTBeKyb6fF1g>
Subject: [secdir] SecDir review of draft-ietf-avtcore-rfc5285-bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 18 Apr 2017 03:24:39 -0000

Hi,
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.


This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized.  The actual extensions in use in a session are signaled in the setup information for that session.  This document obsoletes RFC5285.


The document appears in reasonably good shape.
As a whole, the Security Considerations section analyzes the possible threats to the RTP header extension mechanism, and gives the suitable solutions well.

But, there are still several open issues (TBDs) in the document that need to be completed before publication.
Below a series of my own comments, questions for your consideration.


Comments about the Security Considerations Section:

In fact, [RFC3264] also considers packet confidential protection by encrypting the packet bodies to protect against eavesdropping. This point is missed here.

While Secure Real-time Transport Protocol (SRTP) [RFC3711] covers the same security requirements and measures of RTP header extension mechanism of this draft, but some of its cryptographic algorithms are old and not updated, such as its default and mandatory-to-implement algorithms like: AES-CM and NULL for Encryption, HMAC-SHA1 for Message Authentication/Integrity and so on. Would you please consider to mention this issue in your draft and suggest to use the up to date and secure algorithms to adopt to internet of today. For example, AES-CCM/AES-GCM and HMAC-SHA2_256_128/HMAC-SHA2_512_256?



Editorial suggestions:

Title of section 6: it does not comply with the rule that the first alphabet is capital.

Setion 1: the last paragraph misses a ending "."

A section of Terminology is missed, since there are several words in the draft need this part.

Section 4.1.2: in third paragraph, there is a wrong word "dp", which should be "do".

Section 6: suggest to use "SDP Offer/Answer [RFC3264]" to replace "offer/answer [RFC3264]".


Thank you.


B.R.
Frank