[secdir] secdir review of draft-ietf-ipfix-exporting-type-02
Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 30 March 2009 11:43 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 563FA3A67AC for <secdir@core3.amsl.com>; Mon, 30 Mar 2009 04:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.182
X-Spam-Level:
X-Spam-Status: No, score=-0.182 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1]
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 DqoXDHaid34j for <secdir@core3.amsl.com>; Mon, 30 Mar 2009 04:43:10 -0700 (PDT)
Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 7D8FD3A68E4 for <secdir@ietf.org>; Mon, 30 Mar 2009 04:43:10 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id C12A11003F56E; Mon, 30 Mar 2009 12:44:06 +0100 (IST)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4SQM-8pmREX; Mon, 30 Mar 2009 12:44:06 +0100 (IST)
Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id ED5971003F56B; Mon, 30 Mar 2009 12:44:05 +0100 (IST)
Message-ID: <49D0B0C4.9010603@cs.tcd.ie>
Date: Mon, 30 Mar 2009 12:45:08 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: secdir@ietf.org, draft-ietf-ipfix-exporting-type@tools.ietf.org
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Tim Polk <tim.polk@nist.gov>, Pasi Eronen <Pasi.Eronen@nokia.com>, ipfix-chairs@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-ipfix-exporting-type-02
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: Mon, 30 Mar 2009 11:43:11 -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 a way to include typing information in IPFIX messages. - The security considerations section is just a one liner saying that the same issues apply here as are documented in rfc 5101. In this case that reference is (with the one quibble below:-) sufficient since 5101's security considerations seem to be very comprehensive. - Are the length limits defined somewhere for the strings? E.g. in section 3.3. The concern is buffer overflow etc. so if that's addressed somewhere else that's fine. It may be worth noting this as an additional security consideration since, e.g. the introduction states that collecting processes may use this typing information to store or display otherwise unknown data types. I guess if I could feed a collector arbitrarily complex data types and values I'd be in a good position to try engineer a buffer overrun. Nits: - bottom of p3: s/version of/versions of/ - 3.8 the description is a bit unclear to me (as a naive reader) and the Enterprise bit seems to be referenced here for the 1st time. I'm not at all sure, but it could be that this text is calling for a change to some other RFC (I mean the "SHOULD be cleared" phrase) Regards, Stephen.
- [secdir] secdir review of draft-ietf-ipfix-export… Stephen Farrell