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

Benoit Claise <bclaise@cisco.com> Mon, 18 April 2011 13:29 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94429E07DD; Mon, 18 Apr 2011 06:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level:
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji1+yjk2zK71; Mon, 18 Apr 2011 06:29:48 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfc.amsl.com (Postfix) with ESMTP id 940A1E07D7; Mon, 18 Apr 2011 06:29:46 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3ICoJRt012243; Mon, 18 Apr 2011 14:50:19 +0200 (CEST)
Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3ICoFTT000780; Mon, 18 Apr 2011 14:50:15 +0200 (CEST)
Message-ID: <4DAC3387.8030306@cisco.com>
Date: Mon, 18 Apr 2011 14:50:15 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <4D7F1516.6080401@gmail.com> <4D7F20B2.3070102@cisco.com>
In-Reply-To: <4D7F20B2.3070102@cisco.com>
Content-Type: multipart/alternative; boundary="------------070003010409060808000907"
X-Mailman-Approved-At: Tue, 19 Apr 2011 10:19:34 -0700
Cc: draft-ietf-ipfix-structured-data.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-structured-data-05
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: Mon, 18 Apr 2011 13:29:52 -0000

Hi Yaron,

Discussing with the other authors, we propose:

OLD:

    12. Security Considerations

    The same security considerations as for the IPFIX Protocol
    [RFC5101 <http://tools.ietf.org/html/rfc5101>] and the IPFIX
    information model [RFC5102 <http://tools.ietf.org/html/rfc5102>] apply.


NEW:

    12. Security Considerations

    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.
    Otherwise, the same security considerations as for the IPFIX Protocol
    [RFC5101 <http://tools.ietf.org/html/rfc5101>] and the IPFIX
    information model [RFC5102 <http://tools.ietf.org/html/rfc5102>] apply.

Regards, Benoit.
> Hi Yaron,
>
> Thanks for your feedback.
> Sure we should add your proposed sentence.
>
> Regards, Benoit.
>> 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