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

Yoav Nir <> Thu, 12 July 2012 05:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3CAD21F8718; Wed, 11 Jul 2012 22:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.259
X-Spam-Status: No, score=-10.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KEkwDRTjrSwe; Wed, 11 Jul 2012 22:50:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7698321F8573; Wed, 11 Jul 2012 22:50:23 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id q6C5og8i005735; Thu, 12 Jul 2012 08:50:46 +0300
X-CheckPoint: {4FFE6435-1-1B221DC2-4FFFF}
Received: from ([]) by ([]) with mapi; Thu, 12 Jul 2012 08:50:42 +0300
From: Yoav Nir <>
To: "" <>, " IESG" <>, "" <>
Date: Thu, 12 Jul 2012 08:50:40 +0300
Thread-Topic: [secdir] secdir review of draft-ietf-ipfix-ie-doctors-03
Thread-Index: Ac1f8kW7m91df9JbQjKkatWBOTGI3w==
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [secdir] secdir review of draft-ietf-ipfix-ie-doctors-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jul 2012 05:50:25 -0000

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.


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