Last Call Review of draft-ietf-ipfix-ie-doctors-
review-ietf-ipfix-ie-doctors-secdir-lc-nir-2012-07-13-00

Request Review of draft-ietf-ipfix-ie-doctors
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-07-17
Requested 2012-07-05
Authors Brian Trammell, BenoƮt Claise
Draft last updated 2012-07-13
Completed reviews Genart Last Call review of -?? by Roni Even
Genart Telechat review of -?? by Roni Even
Secdir Last Call review of -?? by Yoav Nir
Assignment Reviewer Yoav Nir
State Completed
Review review-ietf-ipfix-ie-doctors-secdir-lc-nir-2012-07-13
Review completed: 2012-07-13

Review
review-ietf-ipfix-ie-doctors-secdir-lc-nir-2012-07-13

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.

The document defines the criteria by which the "Information Element Doctors" - experts to be appointed by the IESG - should evaluate requests for assignment in the IANA registry for IPFIX information elements. The registry has the "expert review" procedure, and these IE doctors are the designated experts. 

The target audience for this document are two groups: the IE doctors themselves, and the people who request assignments in the registry. The document itself does not define any new protocol or information elements.

The documents has a lot of advice about meaningful names, about avoiding having >1 IEs with the same or similar semantics, and what registry applications should look like.

The Security Considerations section is used in a surprising way. It does not specify how to securely implement this document (as this document specifies no protocol), but it specifies what to consider when evaluating a request for assignment. This is important information, and the section is well-written. IMO there are a few issues with it:

- The section says that you should "not give a potential attacker too much information". It would be better to explicitly list the kinds of threats that leaking too much information may lead to: breach of privacy, vulnerability to traffic analysis, and leaking actual data.

- The section also talks about what should be included in the Internet Draft that specifies the new information element. That I-D would have its own security considerations sections, which would be reviewed in due course, but writing an I-D is not required. Section 9 says that "When a new application is complex enough to require additional clarification or specification as to the use of the defined Information Elements, this may be given in an Internet-Draft." This language is not strong enough to make anything with potential security concerns go though the I-D route. IEs may still be submitted directly to IANA, with the security concerns only mentioned in the IE description. 

I think this document should explicitly state that it is part of the task of IE doctors to consider the security aspects of new IEs, as well as to give guidelines about what they should look for.

Yoav Nir