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

Request Review of draft-ietf-ipfix-protocol-rfc5101bis
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-06-11
Requested 2013-04-18
Authors Paul Aitken, BenoƮt Claise, Brian Trammell
Draft last updated 2013-05-30
Completed reviews Genart Last Call review of -08 by Kathleen Moriarty (diff)
Secdir Last Call review of -06 by Brian Weis (diff)
Secdir Last Call review of -08 by Brian Weis (diff)
Assignment Reviewer Brian Weis 
State Completed
Review review-ietf-ipfix-protocol-rfc5101bis-06-secdir-lc-weis-2013-05-30
Reviewed rev. 06 (document currently at 10)
Review result Has Nits
Review completed: 2013-05-30

Review
review-ietf-ipfix-protocol-rfc5101bis-06-secdir-lc-weis-2013-05-30

(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