Last Call Review of draft-ietf-ipfix-protocol-rfc5101bis-06
review-ietf-ipfix-protocol-rfc5101bis-06-secdir-lc-weis-2013-05-30-00

(Adding Secdir and IETG which I accidentally omitted.)

On May 21, 2013, at 9:40 AM, Brian Trammell <trammell at tik.ee.ethz.ch> wrote:

> Hi, Brian,
>
> Many thanks for the review. Comments inline.
>
> On 21 May 2013, at 18:15 , Brian Weis 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. >> >> This document specifies the IP Flow Information Export (IPFIX)
protocol used to transfer information about network flows to collecting
devices. Most of the document defines data types and record formats that
represent the flow information. The actual objects are not defined.
Implementation of TLS is mandated when IPPIX uses TCP as a transport, and DLTS
when IPFIX uses SCTP or UDP. >> >> The Security Considerations section is
comprehensive and well written. The following comments are relatively minor but
worth considering. >> >> 1. Section 11 describes confidentiality, integrity,
and authentication as important security requirements but omits any mention of
replay protection. Even though replay protection could possibly be implemented
at the IPPIX Collector level using timestamps (I have no idea if it is), it is
still an important service of the security protocol to stop unwanted segments
or packets before decryption. I would suggest adding this as list item 4 in
this section and mentioning in Section 11.1 that both TLS and DTLS perform
replay protection using sequence numbers. > > Replay protection wasn't
considered as a requirement in RFC 3917, possibly because "replays" occur in
many measurement infrastructures where the same packet may be measured at
multiple points, and contribute to multiple flows; therefore much
post-collection analysis is focused on de-duplication, which would catch any
record replay as well. > > (Note as an aside that removing measurement error,
including duplication, from medium-to-large-scale flow collection
infrastructures is still enough of an area of research that a recent student
from our group devoted a chapter thereto in his thesis; at least in the
research community we're enough used to cleaning up dirty flow records that a
simple message replay would present a pleasantly simple challenge. :) > > But
as you say, that's a _record_-level consideration, not a message-level one, and
it's still useful to have message-level replay protection (which we get for
free anyway), so we can certainly note this as you suggest in the next
revision. > >> 2. In Section 11 at the very top of page 50 I would suggest
clarifying the point as s/connection/connection assumed to be unavailable to
attackers/. > > Good point. Will clarify. > >> 3. Section 11.3 mandates certain
versions of TLS. It would be helpful for interoperability to also specify a
mandatory to implement cipher suite. > > We'd sort of presumed that this was
covered by section 9 of RFC 5246 (as I _hope_ that any IPFIX over TLS
implementation will grab a tested TLS implementation off some shelf somewhere,
and pick up the MTI that way), but we can make this explicit.

You're right, the TLS mandatory to implement requirement pretty much satisfies
your need. It's possible that TLS could be updated to declare a different
cipher suite as the mandatory one, so if you thought it was important for IPFIX
interoperability to stick with one you could make it explicit in your document.

Thanks,
Brian

>
> Again, thanks, best regards,
>
> Brian

--
Brian Weis
Security Engineering, SRG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew at cisco.com