[secdir] SecDir review of draft-ietf-ipfix-structured-data-05

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 15 March 2011 07:27 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF593A6C0D; Tue, 15 Mar 2011 00:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psxFJPThTx7i; Tue, 15 Mar 2011 00:27:02 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 23E483A6982; Tue, 15 Mar 2011 00:27:01 -0700 (PDT)
Received: by bwz13 with SMTP id 13so331616bwz.31 for <multiple recipients>; Tue, 15 Mar 2011 00:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=7Am46UOU2J3CYE1Z0/h8VeyCOjvrfkfc7zZqp46UhZE=; b=eyv43CIFM2/4JnND8MbaQsogMYTVMnxVvy+KnTLc5If+WmwI1AN1PPJyowbobKnioG DtxQ8WWinmPW5npxVB0Z1eLxX8x0aw2V+gezEXcNGImsdU+vnv0s+iNGiQglrO1VSdkD 0LK5Q3nvQjgfeeh45ZtixXMA73D2ihqjH9KVU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=L5AspGR9LPG/EmjK6bycMa8x7dYJdaDNgHAEupwzxjJbVDVrT2iqofzLO97ssr2VYZ xAJPIl8qNUtltT1ZiMl3jxxjc4ZIl6LicRS8SLDlBX/pHE+fTiafwNGY/1/faKI4OvRZ 58XlRVajqVf0m+dl8f/I3bioA7V87xcjKTu0I=
Received: by 10.204.169.130 with SMTP id z2mr7077648bky.137.1300174105915; Tue, 15 Mar 2011 00:28:25 -0700 (PDT)
Received: from [192.168.2.104] (IGLD-84-229-42-92.inter.net.il [84.229.42.92]) by mx.google.com with ESMTPS id k5sm240755bku.16.2011.03.15.00.28.23 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 00:28:24 -0700 (PDT)
Message-ID: <4D7F1516.6080401@gmail.com>
Date: Tue, 15 Mar 2011 09:28:22 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ipfix-structured-data.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir review of draft-ietf-ipfix-structured-data-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 15 Mar 2011 07:27:03 -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.

IPFIX is a structured information model and protocol for transmitting 
information about data flows. This document extends the model with 
structured data, basically several types of lists.

I have not reviewed the document in full, rather I have looked at the 
security aspects only. The Security Considerations refer the reader to 
the IPFIX protocol and data model RFCs, and I mostly agree, with one 
exception. I suggest to add text similar to the next paragraph:

The addition of complex data types necessarily complicates the 
implementation of the Collector. This could easily result in new 
security vulnerabilities (e.g., buffer overflows); this creates 
additional risk in cases where either DTLS is not used, or if the 
Observation Point and Collector belong to different trust domains.

Thanks,
	Yaron