Re: [secdir] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09

Brian Trammell <> Fri, 11 January 2013 09:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6773221F873E; Fri, 11 Jan 2013 01:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0E-FlJprZzUE; Fri, 11 Jan 2013 01:24:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9526C21F8629; Fri, 11 Jan 2013 01:24:09 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B97FD930A; Fri, 11 Jan 2013 10:24:06 +0100 (MET)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id IFp6uvcpHGFP; Fri, 11 Jan 2013 10:24:06 +0100 (MET)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by (Postfix) with ESMTPSA id 14CF8D9307; Fri, 11 Jan 2013 10:24:06 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Brian Trammell <>
In-Reply-To: <>
Date: Fri, 11 Jan 2013 10:24:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ben Laurie <>
X-Mailer: Apple Mail (2.1283)
X-Mailman-Approved-At: Fri, 11 Jan 2013 03:24:12 -0800
Cc:, The IESG <>, " Working Group" <>,
Subject: Re: [secdir] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09
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: Fri, 11 Jan 2013 09:24:14 -0000

Hi, Ben,

Many thanks for the review. Comments/questions thereon inline.

On Jan 10, 2013, at 12:55 PM, Ben Laurie <> wrote:

> 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.
> Summary: this document is part of a series of documents describing the
> protocol, and only deals with data elements. As such, most security
> considerations are dealt with elsewhere.

(I'll address the following as comments on 5101 / 5101bis, specifically section 11, which I assume you're referring to...)

> However, I note that whilst a
> good deal of attention is paid to integrity and authentication of the
> data in those other documents, as far as I can see nothing is said
> about authentication of the requester,

As IPFIX is a push protocol designed for operation within a network management infrastructure there is no "requester" per se. There are only exporters and collectors, the former configured (out of band) to send information to the latter, the latter to accept information from the former. Section 11.3 of rfc5101(-bis) addresses authentication of exporters and collectors....

> nor about access control.

...however, while the intention of section 11.3 of RFC5101(-bis) was to state that collectors/exporters should only establish sessions with peers that they could authenticate using TLS mutual authentication, on rereading I see that this isn't explicitly stated in that section. We should fix that.

Section 11 is also a little outdated (at least with respect to terminology for doing DNS-ID lookups) and appears to be needlessly restrictive (e.g., TLS-PSK is not allowed although it would be useful in this case). We should review this as well.

> Given
> that flow information is potentially quite sensitive, this is
> surprising. The document itself seems OK, with nits.

> Nits:
> "3.1.14. string
>   The type "string" represents a finite-length string of valid
>   characters from the Unicode character encoding set
>   [ISO.10646-1.1993].  Unicode allows for ASCII [ISO.646.1991] and many
>   other international character sets to be used."
> RFC 5610 says this is encoded using UTF-8. UTF-8 can have security
> issues, e.g. sending a string with an incomplete UTF-8 encoded
> character, which then swallows part of a following string, or causes
> errors in parsers. Although this document may not be the right place
> for it, it is unfortunate this potential problem is not mentioned.

This is good point. Would you know of an existing description of this problem, ideally with mitigation strategies at the receiver, that we could reference here? Again, I think this would be something to address in 5101bis, as 5102bis is concerned with _abstract_ data types, and 5101bis presents the IPFIX-compatible encoding of those data types.

Best regards,