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

[Brian Trammell <[e-mail]>]

Hi, Ben,

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

On Jan 10, 2013, at 12:55 PM, Ben Laurie <[e-mail]> 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,

Brian