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

From: Yaron Sheffer <[email-masked]>
Date: Thu, 11 Mar 2010 16:47:28 +0200

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.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 11 Mar 2010 16:50:58 +0200

Resending, sorry if you see it twice...

________________________________________
From: Yaron Sheffer
Sent: Thursday, March 11, 2010 4:47 PM
To: [email-masked]; [email-masked]
Subject: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08

Non-security comments

---

From: Tina TSOU <[email-masked]>
Date: Tue, 16 Mar 2010 10:26:47 +0800

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.

A nit: in the first paragraph of section 2, the second sentence is outdated 
and should be deleted.

In paragraph 3 of section 4.2, given that there is no change to the 
TWAMP-test packet format, I assume we use the exact TWAMP-test packet format 
as defined RFC5357, so that the SID is not carried in the test packets. My 
question is that how the reflector just whether a TWAMP-test packet belongs 
to the same session/SID or not. Since per definition the testing message 
does not include SID, how to differentiate the testing message of different 
testing sessions after multiple testing started?

This is not obvious and the text should be improved to make it clear how 
this works.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

---

From: Al Morton <[email-masked]>
Date: Tue, 16 Mar 2010 08:22:36 -0400

Thanks for your comments, Tina.

At 10:26 PM 3/15/2010, Tina TSOU wrote:
>TWAMP-test packet format, I assume we use the exact TWAMP-test 
>packet format as defined RFC5357, so that the SID is not carried in 
>the test packets. My question is that how the reflector just whether 
>a TWAMP-test packet belongs to the same session/SID or not. Since 
>per definition the testing message does not include SID, how to 
>differentiate the testing message of different testing sessions 
>after multiple testing started?
The Request-TW-Session command includes sender address + port
and receiver address + port, and this is usually sufficient.
Al

---

From: Atsushi Kobayashi <[email-masked]>
Date: Wed, 17 Mar 2010 03:19:03 +0900

Dear Yaron,

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

On Thu, 11 Mar 2010 16:50:58 +0200

> Resending, sorry if you see it twice...

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

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 a…

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. 

> 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 cla…

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  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 17 Mar 2010 12:44:26 +0200

Dear Atsushi,

Please see my answers inline.

Thanks,
     Yaron

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

Dear Yaron,

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

Yes.

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

I have two scenarios.

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

[YS] Good. Thanks.

---

Scanned by Check Point Total Security Gateway.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 18 Mar 2010 10:37:33 +0800

B. R.
Tina

----- Original Message ----- 
From: "Al Morton" <[email-masked]>
To: "Tina TSOU" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 16, 2010 8:22 PM
Subject: Re: SecDir review of draft-ietf-ippm-twamp-session-cntrl-04

>>TWAMP-test packet format, I assume we use the exact TWAMP-test packet 
>>format as defined RFC5357, so that the SID is not carried in the test 
>>packets. My question is that how the reflector just whether a TWAMP-test 
>>packet belongs to the same session/SID or not. Since per definition the 
>>testing message does not include SID, how to differentiate the testing 
>>message of different testing sessions after multiple testing started?
Can the server identify the corresponding SID based on sender address + port 
and  receiver address + port?

---

From: Al Morton <[email-masked]>
Date: Thu, 18 Mar 2010 08:10:44 -0400

At 10:37 PM 3/17/2010, Tina TSOU wrote:
>>>In paragraph 3 of section 4.2, given that there is no change to 
>>>the TWAMP-test packet format, I assume we use the exact TWAMP-test 
>>>packet format as defined RFC5357, so that the SID is not carried 
>>>in the test packets. My question is that how the reflector just 
>>>whether a TWAMP-test packet belongs to the same session/SID or 
>>>not. Since per definition the testing message does not include 
>>>SID, how to differentiate the testing message of different testing 
>>>sessions after multiple testing started?
>Can the server identify the corresponding SID based on sender 
>address + port and  receiver address + port?

Yes, the server assigns the SID with all addr+port information in hand.

---

From: Atsushi Kobayashi <[email-masked]>
Date: Fri, 19 Mar 2010 16:57:10 +0900

Dear Yaron,

Thank you for quick reply. Please see in-line as usual.

On Wed, 17 Mar 2010 12:44:26 +0200

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

Ok, but, this issue is more general. If there is no Mediator, 
collecting Flow Records from multiple sources raises the risk for privacy. 
I am not sure what description suitable for this document. Even if I say
so, my idea is as follows.

   o  Privacy concerns on an IPFIX Mediator

      The probability to get specific user's traffic generally increases
      by increasing the number of Observation Points.  An IPFIX Mediator
      collecting Flow Records from multiple Observation Points
      potentially raises the risk for privacy.  Thus, the IPFIX Mediator
      needs to apply appropriately anonymization or aggregation function
      to Data Records to cope with privacy concerns.

      In addition, an IPFIX Mediator needs to identify the user's
      identifier, e.g., IP addess, VLAN ID, MAC address, and etc., when
      feeding user's traffic data to an user own dedicated IPFIX
      Collector.  If the IPFIX Mediator can not identify each user, it
      may need to drop the Data Records.

How about that? Some description will be changed after discussing it
with co-authors.

> http://en.wikipedia.org/wiki/Information_security

I will merge above the paragraph into "privacy concern" bullet.

> [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, o…

Yes. It is too hard for an IPFIX Collector to confirm the integrity of
original Data Record. At this level, I will remove term "integrity" from
this paragraph.

   o  Confidentiality protection via IPFIX Mediator

      To ensure confidentiality of Data Records, its transport for Data
      Records should use Transport Layer Security (TLS) or Datagram
      Transport Layer Security (DTLS).  However, an IPFIX Collector
      cannot know whether received Data Records are transported as
      encrypted data between an Original Exporter and an IPFIX Mediator.
      Some function is required to make up for this drawback.

> [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 probl…

Ok, I will put it into this section.

   o  Certification for an Original Exporter

      An IPFIX Collector communicating via an IPFIX Mediator can not
      certificate an Original Exporter directly.  If each device is
      located in different administrative domain, an IPFIX Collector can
      not trust its Data Records.  Some function is required to make up
      for this drawback.

Regards,
Atsushi

---

---

From: Atsushi Kobayashi <[email-masked]>
Date: Mon, 22 Mar 2010 12:29:24 +0900

Dear Yaron,

After discussing with co-author, I will rewrite security consideration
section as follows. I think this version covers your concerns.

You can see the difference between the current and new version.
http://www.nttv6.net/~akoba/wdiff-ps08-ps09-02.htm

I would like to receive your go-ahead before IPFIX meeting within Monday.
Is it OK?

--------------------
8.  Security Considerations

   A flow-based measurement system must prevent potential security
   threats: the disclosure of confidential traffic data, injection of
   incorrect data, and unauthorized access to traffic data.  These
   security threats of the IPFIX protocol are covered by the security
   considerations section in [RFC5101] and are still valid for IPFIX
   Mediators.

   A measurement system must also prevent the following security threats
   related to IPFIX Mediation:

   o  Attacks against an IPFIX Mediator

      IPFIX Mediators can be considered as a prime target for attacks,
      as an alternative to IPFIX Exporters and Collectors.  IPFIX
      Proxies or Masquerading Proxies need to prevent unauthorized
      access or denial-of-service (DoS) attacks from untrusted public
      networks.

   o  Man-in-the-middle attack by untrusted IPFIX Mediator

      The Exporter-Mediator-Collector structure model could be misused
      for man-in-the-middle attack.

   o  Configuration on IPFIX Mediation

      An accidental misconfiguration and unauthorized access to
      configuration data could lead to the crucial problem of disclosure
      of confidential traffic data.

      The probability to get specific user's traffic generally increases
      by increasing the number of Observation Points.  An IPFIX Mediator
      collecting Flow Records from multiple Observation Points
      potentially raises the risk for privacy.  The IPFIX Mediator needs
      to apply appropriately anonymization or aggregation function to
      Data Records to avoid the risk for privacy, when the purpose of
      traffic measurement is not to monitor specific user's traffic
      trend.

      On the other hand, an IPFIX Mediator needs to identify the user's
      identifier, e.g., IP addess, VLAN ID, MAC address, and etc., when
      feeding user's traffic data to an user own dedicated IPFIX
      Collector.  If the IPFIX Mediator can not identify each user, it
      may need to drop the Flow Records.

   o  Confidentiality protection via an IPFIX Mediator

      To ensure confidentiality of Data Records, its transport for Data
      Records should use Transport Layer Security (TLS) [RFC4346] or
      Datagram Transport Layer Security (DTLS) [RFC4347].  However, an
      IPFIX Collector can not know whether received Data Records are
      transported as encrypted data between an Original Exporter and an
      IPFIX Mediator.  If this information is required on the IPFIX
      Collector, it must be encoded in the IPFIX Mediator.

      An IPFIX Collector communicating via an IPFIX Mediator can not
      verify the identity of an Original Exporter directly.  If an
      Original Exporter and an IPFIX Collector are located in different
      administrative domains, an IPFIX Collector can not trust its Data
      Records.  If this information is required on the IPFIX Collector,
      it must be encoded in the IPFIX Mediator.

Regards,
Atsushi

On Fri, 19 Mar 2010 16:57:10 +0900

-- 
Atsushi Kobayashi <[email-masked]>