[secdir] SecDir review of draft-ietf-ipfix-mediators-problem-statement-08

Yaron Sheffer <yaronf@checkpoint.com> Thu, 11 March 2010 14:47 UTC

Return-Path: <yaronf@checkpoint.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 5E0DC3A690F for <secdir@core3.amsl.com>; Thu, 11 Mar 2010 06:47:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.455
X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3HFv9s277o+G for <secdir@core3.amsl.com>; Thu, 11 Mar 2010 06:47:11 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com []) by core3.amsl.com (Postfix) with ESMTP id 77F6F3A6BB8 for <secdir@ietf.org>; Thu, 11 Mar 2010 06:47:04 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com []) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2BEl8sd007062; Thu, 11 Mar 2010 16:47:08 +0200 (IST)
X-CheckPoint: {4B9900D1-0-1B201DC2-2FFFF}
Received: from il-ex01.ad.checkpoint.com ([]) by il-ex01.ad.checkpoint.com ([]) with mapi; Thu, 11 Mar 2010 16:47:29 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ipfix-mediators-problem-statement.all@ietf.org" <draft-ietf-ipfix-mediators-problem-statement.all@ietf.org>
Date: Thu, 11 Mar 2010 16:47:28 +0200
Thread-Topic: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08
Thread-Index: AQHKwSnFhimeoX26UUOjJSTKNbzCAA==
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] SecDir review of draft-ietf-ipfix-mediators-problem-statement-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 11 Mar 2010 14:47:12 -0000

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 presents the need for introducing Mediators (known in other quarters as "proxies") into the IPFIX architecture.

The document is in general well written, and it does attempt to cover most of the relevant security issues. But I would have liked to see a bit more discussion on:

- Privacy concerns, especially where actual data packets are sampled. These concerns may be amplified when streams from multiple sources are combined.
- Multi-tenancy: large networks, i.e. those that require such solutions, may process and sometime aggregate data from many different owners. An extreme example is virtualized processing clouds. Tenants should be protected from one another, and possibly also from the service provider.
- The subsection of the Security Considerations that discusses confidentiality protection could be improved to more clearly point out that transport-level security is no longer sufficient in this architecture, and (at least in some cases) should be replaced by end-to-end, application-level security.
- The trust model should be clarified, possibly just to say "we all trust the Mediator".

Non-security comments

The document starts out by discussing IPFIX, and then suddenly in 3.2, PSAMP is introduced. The clueless reader is left confused: how does PSAMP relate to per-flow information? I'd appreciate a clarifying paragraph at the top of Sec. 3.