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

Yaron Sheffer <> Wed, 17 March 2010 10:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66F163A6859 for <>; Wed, 17 Mar 2010 03:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.926
X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id irJff5icciYo for <>; Wed, 17 Mar 2010 03:44:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 152693A69D3 for <>; Wed, 17 Mar 2010 03:43:58 -0700 (PDT)
Received: from ( []) by (8.12.10+Sun/8.12.10) with ESMTP id o2HAi6sd024568; Wed, 17 Mar 2010 12:44:06 +0200 (IST)
X-CheckPoint: {4BA0B217-0-1211DC2-2FFFF}
Received: from ([]) by ([]) with mapi; Wed, 17 Mar 2010 12:44:28 +0200
From: Yaron Sheffer <>
To: Atsushi Kobayashi <>
Date: Wed, 17 Mar 2010 12:44:26 +0200
Thread-Topic: Re[2]: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08
Thread-Index: AcrFNgMq5U1Z4m3YQH6wAzyw+AlK2gAhy+hf
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
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
X-Mailman-Approved-At: Wed, 17 Mar 2010 03:57:03 -0700
Cc: "" <>, "" <>
Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-mediators-problem-statement-08
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Mar 2010 10:55:04 -0000

Dear Atsushi,

Please see my answers inline.


From: Atsushi Kobayashi []
Sent: Tuesday, March 16, 2010 8:19 PM
To: Yaron Sheffer
Subject: Re[2]: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08

Dear Yaron,

Thank you for your feedbacks. Please see in-line.

On Thu, 11 Mar 2010 16:50:58 +0200
Yaron Sheffer <> wrote:

> Resending, sorry if you see it twice...
> ________________________________________
> From: Yaron Sheffer
> Sent: Thursday, March 11, 2010 4:47 PM
> To:;
> 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.

Could you please clarify your concerns.
I assume your concerns as follows.

a) Flow Records from multiple sources can reveal the path for flows. It
may create another privacy issue.

b) Generally, it is difficult that random sampling technique captures
specific customer's traffic. However, the probability to capture
specific customer's traffic increases, when there are multiple
observation points.

I think a) and b) are general privacy issues regarding flow-based
measurement whether there are intermediate devices or not.

[YS] I was thinking more of point (b) above. And as you say, when you have multiple observation points, this problem potentially becomes more acute.

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


It needs to identify the customer's identifier, e.g., IP addess, vlan,
mac address, and etc., to feed them to appropriate intermediate process
anonymizing them, and to export them to Collector to separate one another.

When an IPFIX Mediator can not identify the customer, in special case
where VM motion occurs, it may need to drop the flow records.

I will put above paragraph in sentence.

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

Actually, the scope of this document is problem statement. It is just
starting points to continue to the series of IPFIX Mediation documents.

At this level, I can not come up with the suitable end-to-end
confidentiality protection method via Mediator. If the
confidentiality protection for Flow Records is kept on Mediators,
Mediator would not be able to handle Flow Records. Could you please
show some cases you mentioned.

[YS] I was thinking of integrity protection, rather than confidentiality protection, i.e. the Mediator can still see the traffic. But I agree that even this is impractical for a generic Mediator, one which is expected to modify records, merge multiple records etc. So I cannot offer a good solution here. But I had an issue with the first sentence "To ensure integrity and confidentiality of Data Records, its transport for Data Records should use Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS). " This sounds like a specific solution would solve the problem, and I believe this is not the case.

> - The trust model should be clarified, possibly just to say "we all trust the Mediator".

I have two scenarios.

a) A Collector certificates a Mediator by using X.509 certificates, and
the Collector certificates an Original Exporter by its X.509
certificates informed by the Mediator.

b) A Collector certificates a Mediator by using X.509 certificates, and
the Collector receives the report that the Mediator certificates
an Original Exporter.

Case a) is recommended. Case b) can be applied to the following cases,
service providers feed customer flow data, and also would like to avoid
to disclose the network devices information, that is exporters. Any
other cases should be avoid so far.

I think the above description should be put into the later framework
document as some requirement.

[YS] This is fine, what you are describing above is a solution outline. But a few words describing the use cases (closed network vs. ISP?) in the context of trust would be appropriate for the problem statement as well.

I will discussed with authors and WG members.

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

Ok, I will put the following paragraph at the top of section 3.

IPFIX Mediation can be applied to flow- or packet-based information.
The flow-based information is encoded by IPFIX protocol, and the
packet-based information is extracted by some sampling techniques and
then encoded by PSAMP protocol. Thus, this section describes relevant
documents for both protocols.

[YS] Good. Thanks.

Atsushi KOBAYASHI  <>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

Scanned by Check Point Total Security Gateway.