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