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

[Atsushi Kobayashi <[e-mail]>]

Dear Yaron,

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

On Thu, 11 Mar 2010 16:50:58 +0200
Yaron Sheffer <[e-mail]> wrote:

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

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

Yes.

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.

> - 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. 
http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-05

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.

--- 
Atsushi KOBAYASHI  <[e-mail]>
NTT Information Sharing Platform Lab.
tel:[phone] fax:[phone]