Skip to main content

Last Call Review of draft-ietf-avtcore-rfc5285-bis-09
review-ietf-avtcore-rfc5285-bis-09-secdir-lc-xia-2017-04-20-00

Request Review of draft-ietf-avtcore-rfc5285-bis
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-04-20
Requested 2017-04-06
Authors David Singer , HariKishan Desineni , Roni Even
I-D last updated 2017-04-20
Completed reviews Opsdir Last Call review of -09 by Carlos M. Martínez (diff)
Secdir Last Call review of -09 by Liang Xia (diff)
Genart Last Call review of -11 by Vijay K. Gurbani (diff)
Secdir Telechat review of -12 by Liang Xia (diff)
Assignment Reviewer Liang Xia
State Completed
Request Last Call review on draft-ietf-avtcore-rfc5285-bis by Security Area Directorate Assigned
Reviewed revision 09 (document currently at 14)
Result Has issues
Completed 2017-04-20
review-ietf-avtcore-rfc5285-bis-09-secdir-lc-xia-2017-04-20-00
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