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

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

Return-Path: <yaronf@checkpoint.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3793A6BD4 for <secdir@core3.amsl.com>; Thu, 11 Mar 2010 06:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.466
X-Spam-Level:
X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMJaxrEm0i49 for <secdir@core3.amsl.com>; Thu, 11 Mar 2010 06:53:25 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id CC3C03A6922 for <secdir@ietf.org>; Thu, 11 Mar 2010 06:51:55 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2BEq0sd007998; Thu, 11 Mar 2010 16:52:00 +0200 (IST)
X-CheckPoint: {4B9901F5-1-1B201DC2-2FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 11 Mar 2010 16:52:21 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org" <draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org>
Date: Thu, 11 Mar 2010 16:50:58 +0200
Thread-Topic: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08
Thread-Index: AQHKwSnFhimeoX26UUOjJSTKNbzCAJHs0jFZ
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C898@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [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:53:26 -0000

Resending, sorry if you see it twice...

________________________________________
From: Yaron Sheffer
Sent: Thursday, March 11, 2010 4:47 PM
To: secdir@ietf.org; draft-ietf-ipfix-mediators-problem-statement.all@ietf.org
Subject: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08

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.