Skip to main content

Last Call Review of draft-ietf-ipfix-file-

Request Review of draft-ietf-ipfix-file
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-04-03
Requested 2009-03-24
Authors Lutz Mark , Arno Wagner , Elisa Boschi , Tanja Zseby , Brian Trammell
I-D last updated 2009-04-09
Completed reviews Secdir Last Call review of -?? by Sam Hartman
Assignment Reviewer Sam Hartman
State Completed
Review review-ietf-ipfix-file-secdir-lc-hartman-2009-04-09
Completed 2009-04-09
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.

This draft specifies a file format for storing and transporting flow
data.  Typically the flow data will be collecting in the IPFIX format,
although it is of course potentially possibly to convert other flow
data to use this format; section 6 discusses such a case.

I urge the IESG to get specific additional review from the law
enforcement/security investigation community surrounding the handling
of evidence in an ongoing investigation prior to approving this draft.
Section 4 cites that use case as a significant motivation.  However,
I'm concerned that the requirements in section 5 and thus the
resulting protocol are inadequate to that community's needs.

Section 3 talks about advantages of the file format including that
files can be concatenated or split on message boundaries.  There is no
file header or trailer.  However there are records such as those
described in 8.1.3 that describe metadata for the file.  Particularly
in investigation environments it seems problematic to get into a
situation where the file has metadata that claims inaccurately to
describe the file especially when this happens using mechanisms
explicitly supported by the file format and the situation cannot be
detected.  In the document use case I think you want a mechanism to
confirm that a file has not been added to or removed from.

Section 7.3.4 requires using the file write time as the export time.
That seems potentially problematic in an investigation.  TPerhaps the
message details option in 8.1.4 is supposed to handle this; if so,
text explaining how this works should be added to 7.3.4.

The handling of authentication seems problematic.  The text points out
that TLS can be used to provide transient authentication from the
exporter to collector.  Discussion of the lack of data origin
authentication (authentication that can be verified after the fact by
a third party) needs to be added to the security considerations
section; this seems important for the 7.3.4 use case.  I'm not asking
for digital signatures to be added at the exporter, simply for
discussion of the consequences on having hop-by-hop authentication.

However there is a more serious lack on the authentication front.
There is no way for a file writer to describe the authenticated
identity of the exporter.  I'd expect 8.1.3 and 8.1.4 to include
attributes to describe the TLS identity of the exporter.

The template in 8.1.1 uses md5.  There's insufficient documentation
for me to tell whether the cryptographic properties, particularly
collision resistance, are important to this use of md5.  My guess is
that they are and thus md5 may not be the best hash to use.
Is a per-message checksum really the right granularity?

The security considerations section is very weak.