Skip to main content

Early Review of draft-ietf-dime-app-design-guide-19
review-ietf-dime-app-design-guide-19-secdir-early-nir-2013-09-19-00

Request Review of draft-ietf-dime-app-design-guide
Requested revision No specific revision (document currently at 28)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2014-08-05
Requested 2013-09-12
Authors Lionel Morand , Victor Fajardo , Hannes Tschofenig
I-D last updated 2013-09-19
Completed reviews Genart Early review of -19 by Martin Thomson (diff)
Secdir Early review of -19 by Yoav Nir (diff)
Opsdir Early review of -20 by David Kessens (diff)
Opsdir Telechat review of -26 by Benoît Claise (diff)
Assignment Reviewer Yoav Nir
State Completed
Request Early review on draft-ietf-dime-app-design-guide by Security Area Directorate Assigned
Reviewed revision 19 (document currently at 28)
Result Has nits
Completed 2013-09-19
review-ietf-dime-app-design-guide-19-secdir-early-nir-2013-09-19-00
Do not be alarmed.  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.

Summary: The document is ready for publication

This informational document provides guidance on extending Diameter
applications and on creating new ones. It contains advice such as to re-use
existing commands and AVPs, considerations for adding and deleting commands and
AVPs, and accounting.

Section 5.11 talks about Diameter security mechanisms: (D)TLS or IPsec. Some
might dislike that it still mentions IKEv1. I'm not sure why this section is
necessary at all, as these security mechanisms apply to the base protocol
rather than any particular extension.

There is a 2-page section dealing with registration considerations, but only a
very short paragraph for security considerations. That section pretty much says
that extensions may be related to security functionality, but the document does
not give guidance on enhancing Diameter with respect to security. I agree that
this is OK, and new security functionality should specify its own
considerations. I do wonder, though, whether it makes sense to include advice
about the content in new data and applications as it relates to security,
specifically as it relates to data leakage or data aggregation or user privacy.

Nit:

Second sentence in the security considerations section:
OLD:
 Although such an extension may related to security functionality,
NEW:
 Although such an extension may be related to security functionality,

Yoav