Re: [secdir] Secdir review of draft-ietf-ipfix-protocol-rfc5101bis-06

Brian Weis <bew@cisco.com> Tue, 21 May 2013 16:57 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0CE21F9588; Tue, 21 May 2013 09:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b2tjrALrOiD; Tue, 21 May 2013 09:57:09 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 60BA621F93C8; Tue, 21 May 2013 09:57:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3978; q=dns/txt; s=iport; t=1369155429; x=1370365029; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=C3PYm5bu1aY4yXzhZoUz4ReS82QCTzp+ApzK2jFSUuI=; b=fcnFBhPU4zMbYQJUaf8Bw9t2rQM11yamWk8k1IJh9jGs149mrKxbC8XL tn7ul3mUmpqvFLbrp50LjMM/4hISiJL6sfICIIOGJYfubujEDFHSsFo+Y hm54pwReV0Baw3RgrgHje6VW4PClLBQ2L0eoCmYk+UPE7zR1Kjr46/Yf3 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJSmm1GrRDoJ/2dsb2JhbABWA4MIwX+BCxZ0giMBAQEDATo2CQULCxguVwYKCRSHcwW7Yo1YgQ8jEAcRgmJhA4kfjhmRQIMvHIE1
X-IronPort-AV: E=Sophos;i="4.87,715,1363132800"; d="scan'208";a="79188945"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 21 May 2013 16:57:08 +0000
Received: from sjc-vpn6-693.cisco.com (sjc-vpn6-693.cisco.com [10.21.122.181]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4LGv8WV002230; Tue, 21 May 2013 16:57:08 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Brian Weis <bew@cisco.com>
In-Reply-To: <0A45961E-0E4B-40C1-B2DA-A4855778FF5E@tik.ee.ethz.ch>
Date: Tue, 21 May 2013 09:57:07 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA2AABC3-E633-476D-9A54-00C8B39315E8@cisco.com>
References: <7F342100-9456-4FF8-A19D-4F892AEEBB00@cisco.com> <0A45961E-0E4B-40C1-B2DA-A4855778FF5E@tik.ee.ethz.ch>
To: Brian Trammell <trammell@tik.ee.ethz.ch>
X-Mailer: Apple Mail (2.1503)
Cc: draft-ietf-ipfix-protocol-rfc5101bis.all@tools.ietf.org, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-ipfix-protocol-rfc5101bis-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2013 16:57:14 -0000

(Adding Secdir and IETG which I accidentally omitted.)

On May 21, 2013, at 9:40 AM, Brian Trammell <trammell@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@cisco.com