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

Yoav Nir <ynir@checkpoint.com> Wed, 11 July 2012 11:26 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 398B721F84CD; Wed, 11 Jul 2012 04:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.235
X-Spam-Status: No, score=-10.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QGWNJN73UBmM; Wed, 11 Jul 2012 04:26:45 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3B4D821F847E; Wed, 11 Jul 2012 04:26:44 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com []) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6BBRCTl005414; Wed, 11 Jul 2012 14:27:12 +0300
X-CheckPoint: {4FFD619D-1-1B221DC2-4FFFF}
Received: from il-ex01.ad.checkpoint.com ([]) by il-ex01.ad.checkpoint.com ([]) with mapi; Wed, 11 Jul 2012 14:27:12 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org IESG" <iesg@ietf.org>, "draft-ietf-ipfix-ie-doctors.all@tools.ietf.org" <draft-ietf-ipfix-ie-doctors.all@tools.ietf.org>
Date: Wed, 11 Jul 2012 14:27:13 +0300
Thread-Topic: secdir review of draft-ietf-ipfix-ie-doctors-03
Thread-Index: Ac1fWBwy1r8fRA9fRqCV3KYfY5T/tA==
Message-ID: <56C143E9-A517-4DDE-8CCC-3C4E1B0FF17F@checkpoint.com>
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: [secdir] secdir review of draft-ietf-ipfix-ie-doctors-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 11:26:46 -0000


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