Last Call Review of draft-ietf-rmt-sec-discussion-08

Request Review of draft-ietf-rmt-sec-discussion
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-06-20
Requested 2013-06-07
Authors Brian Adamson, Vincent Roca, Hitoshi Asaeda
Draft last updated 2013-06-20
Completed reviews Secdir Last Call review of -08 by Klaas Wierenga
Assignment Reviewer Klaas Wierenga 
State Completed
Review review-ietf-rmt-sec-discussion-08-secdir-lc-wierenga-2013-06-20
Reviewed rev. 08
Review result Has Issues
Review completed: 2013-06-20



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 describes general security considerations for Reliable
Multicast Transport (RMT) building blocks and protocols. However the discussion is not limited to RMT per se but is rather a discussion in general about security issues that may influence the overall security of RMT.

I have one major issue with this draft, I interpret the discussion sort of as a lengthy security considerations section for RMT. And while I applaud the effort that has gone into producing this draft I don't understand why you have not looked at RFC3552 (guidelines for writing security considerations) and take that as the starting point of your discussion. It appears to me that that would have been a more rigorous approach (for example, it is unclear to me why you have a discussion about IPSec, but not about TLS, to name an example). It would also have meant that you could reuse much of the text there or simply refer to it. We now end up with 2 documents that write about the same sort of issues but in different wording and in the case of this draft, far less scrutiny from the security community. In the current incantation I don't support forwarding the document, either it will have to be more rigorous (but still with the concern about doubling the work) or should refer to RFC3552 and just discuss the RMT specific issues and implementation choices.

Hope this helps,