Return-Path: 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:29:52 -0000 This is a multi-part message in MIME format. --------------070003010409060808000907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Yaron, Discussing with the other authors, we propose: OLD: 12. Security Considerations The same security considerations as for the IPFIX Protocol [RFC5101 ] and the IPFIX information model [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 ] and the IPFIX information model [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 --------------070003010409060808000907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Yaron,

Discussing with the other authors, we propose:

OLD:
12. Security Considerations

The same security considerations as for the IPFIX Protocol
[RFC5101] and the IPFIX information model [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] and the IPFIX information model [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

--------------070003010409060808000907--