[secdir] SECDIR review of draft-ietf-ipfix-mediation-protocol-07

Stephen Kent <kent@bbn.com> Thu, 17 October 2013 17:23 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D05C711E82C5 for <secdir@ietfa.amsl.com>; Thu, 17 Oct 2013 10:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.503
X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CwwPYLcaRS9F for <secdir@ietfa.amsl.com>; Thu, 17 Oct 2013 10:23:44 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com []) by ietfa.amsl.com (Postfix) with ESMTP id AF98A11E82B9 for <secdir@ietf.org>; Thu, 17 Oct 2013 10:23:43 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([]:54554) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1VWrIF-000M47-Og; Thu, 17 Oct 2013 13:23:27 -0400
Message-ID: <52601D0F.9030702@bbn.com>
Date: Thu, 17 Oct 2013 13:23:27 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: secdir <secdir@ietf.org>, bclaise@cisco.com, akoba@nttv6.net, Brian Trammell <trammell@tik.ee.ethz.ch>, n.brownlee@auckland.ac.nz, quittek@neclab.eu
Content-Type: multipart/alternative; boundary="------------070001060109050006020308"
Subject: [secdir] SECDIR review of draft-ietf-ipfix-mediation-protocol-07
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: Thu, 17 Oct 2013 17:24:03 -0000

I 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.

The document describes how IPFIX (IP Flow Information Export) operates 
in the context of IPFIX "mediators." In the IPFIX context, a mediator is 
an entity that processes data received from an "exporter" (e.g., a 
router), before passing the data to a consuming entity (e.g., a network 
management system), in theb IPFIX format. A mediator can perform various 
types of processing on IPFIX data, e.g., aggregation, correlation, and 
anonymizing, in addition to format conversion.

The security considerations section in this document is brief, just 
three paragraphs. It cites the corresponding sections of RFC 7011 (the 
base IPFIX specification) and RFC 5655 (the IPFIX file specification). 
It also addresses two considerations that the authors view as specific 
to the mediator context. Specifically, the authors note that a mediator 
is an MITM, and thus the confidentiality and integrity of the IP flow 
data that traverses a mediator can be affected. The authors note 
although one can use certificates to identify upstream source of 
processing entities (supported by data elements defined in RFC 5655), 
this does not provide secure, end-to-end assertions about the upstream 
entities.Both of these considerations are accurate an well-described here.

I briefly examined the security considerations sections of the cited 
RFCs. I was impressed by the scope of the security discussion in RFC 
7011; it mandates support for TLS (v1.1 or later) and DTLS, and calls 
for (SHOULD) use of certificates in support of mutual authentication of 
IPFIX entities. There is even a DoS discussion. Good job!

The security considerations section of RFC 5655 is shorter, but also 
appropriate for its context. 5655 calls for (SHOULD) use of CMS (vs. TLS 
and DTLS) for IPFIX files. It also examines additional security issues 
relevant to the files. (I have one minor quibble with the text here; it 
refers to using TLS to "sign" data, which is not correct. The integrity 
and authentication mechanisms offered by TLS do not include signatures.) 
Citing the security considerations sections of these other RFcs was 

I wish more I-Ds did as good a job as this one (and its predecessor 
RFCs) with respect to security considerations sections.