Re: [secdir] secdir review of draft-ietf-ipfix-ie-doctors-03

[Brian Trammell <[e-mail]>]

Hi, Yoav,

Many thanks for the review (and the summary, which did indeed make it easier to read)... I believe that revision -04 of the document addresses these.

Best regards,

Brian

On Jul 12, 2012, at 7:50 AM, Yoav Nir wrote:

> Reading my own review again, I think it's missing a summary.
> 
> The draft does a good job of describing the need to review new information elements for the security implications of sending them in IPFIX.  I'm missing two things:
> 
> 1. A list of security and privacy issues to consider (PII, actual data leakage, traffic flow data)
> 2. A clear statement that the IE doctors need to make these considerations. That would be clearer if the security stuff (that is part of the review process) was not in the "Security Considerations" section, but could be made clear with a clarifying sentence.
> 
> Yoav
> 
> On Jul 11, 2012, at 2:27 PM, Yoav Nir wrote:
> 
>> 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
>>