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

[Atsushi Kobayashi <[e-mail]>]

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.

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

   o  Certification for an Original Exporter

      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 <[e-mail]> wrote:

> 
> Dear Yaron,
> 
> Thank you for quick reply. Please see in-line as usual.
> 
> On Wed, 17 Mar 2010 12:44:26 +0200
> Yaron Sheffer <[e-mail]> wrote:
> 
> > Dear Atsushi,
> > 
> > Please see my answers inline.
> > 
> > Thanks,
> >      Yaron
> > 
> > ________________________________________
> > From: Atsushi Kobayashi [[e-mail]]
> > Sent: Tuesday, March 16, 2010 8:19 PM
> > To: Yaron Sheffer
> > Cc: [e-mail]; [e-mail]
> > 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 <[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.
> > 
> > [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.
> 
> > 
> > > - 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.
> > http://en.wikipedia.org/wiki/Information_security
> > I will put above paragraph in sentence.
> 
> I will merge above the paragraph into "privacy concern" bullet.
> 
> > 
> > > - 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.
> > 
> 
> 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.
> 
> > > - 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
> > 
> > [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.
> > 
> 
> 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
> 
> 
> > 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  <[e-mail]>
> > NTT Information Sharing Platform Lab.
> > tel:[phone] fax:[phone]
> > 
> > 
> > 
> > Scanned by Check Point Total Security Gateway.
> 
> --- 
> Atsushi KOBAYASHI  <[e-mail]>
> NTT Information Sharing Platform Lab.
> tel:[phone] fax:[phone]

-- 
Atsushi Kobayashi <[e-mail]>