Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-framework-06

From: Atsushi Kobayashi <[email-masked]>
Date: Fri, 11 Jun 2010 16:59:22 +0900

Hi Christoph,

Thank you for your feedback.

Sorry for late reply. Please see in-line as usual.

On Fri, 28 May 2010 12:12:51 -0400
Christoph Sommer <[email-masked]> wrote:

> Dear all,
> 
> Atsushi Kobayashi wrote:
> > Could you please read the framework draft and put your feedbacks in ipfix mailing list.
> 
> I really like how the current draft spells out very clearly what IPFIX 
> Mediation is (the manipulation of a record stream) and how this is 
> achieved (via Intermediate Processes)!
> 
> What worries me a bit, however, is that after reading the draft I don't 
> have a solid grasp on just what an IPFIX Mediator is and where 
> Intermediate Processes can be used.
> 
> Is an IPFIX Mediator a device that *does* IPFIX Mediation?
> 
> Is an IPFIX Mediator a device that *can do* IPFIX Mediation?
> 
> More generally, is an IPFIX Mediator *required* to host:
> - a Collecting Process?
> - an Intermediate Process?
> - an Exporting Process?
> 
> What is the relationship of an IPFIX Mediator and an IPFIX 
> Collector/Exporter?
> 
> Or, even more generally -- with "C", "I", and "E" being one or more 
> (active) Collecting, Intermediate, and Exporting Processes, respectively 
> -- which of the following are IPFIX Mediators, IPFIX Collectors and/or 
> IPFIX Exporters:
> 
> ||
> 
> |C|
> 
> |I|
> 
> |E|
> 
> |CI|
> 
> |IE|
> 
> |CIE|
> 
> 
> Lastly, here are some random thoughts I had while reading the draft:
> 
> - Figure A and Figure I are conflicting. It seems like most of the 
> document outright forbids running an Intermediate Process on anything 
> other than a Mediator or Exporter, yet Figure I shows a device that does 
> just that.
> 

This document does not intend to forbid an Intermediate process is 
hosted in devices other than collector and exporter.

Simply, although Collector can host an Intermediate process, 
it does not export any data to other devices. 
It is out of scope of this document, because Collector does not have 
something to use IPFIX Protocol. 

Figure I shows the relation between an Intermediate process and 
IPFIX File Writer, which operates as an Exporting Process according to RFC5655.
In that case, the device hosts CP, IP, and specifc EP(File Writer); exports data 
to File system using IPFIX protocol. Thus, the document covers the condition.

Is it OK?

> - Figure A labels the devices "Collector 1 .. N", "Exporter 1 .. N", and 
> "Source 1 .. N". However, Mediators are labeled "Mediator 1 .. N and M 
> .. Z".
> 

Ok, I will improve them to "Mediator 1 .. N".

> - Figure B does not seem to allow the Intermediate Process to receive 
> data from sources other than the Collecting Process.
> 

Other cases are allowed in Figure C-E. Figure B shows typical case.

> - I didn't understand what Section 7, Paragraph "Sequence Number" means.

I mean:

Even if an IPFIX Mediator relays a one-to-one Transport Session, 
relays incoming IPFIX messages, and operates only message level, 
the IPFIX Mediator needs to handle the Sequence Number properly.

When the incoming session shuts down and re-starts, the sequence 
number in outgoing session is not allowed to be initialized.

Is it OK?
> 
> - Section 9, Paragraph "Certification" states that all Mediators are 
> *recommended* to export an additional x.509 certificate, but in certain 
> cases do not *need* to. Also, I think it might be worthwhile to state 
> the reason for this recommendation and the exception more clearly.
> 

In the case where an IPFIX Mediator acts as the proxy of Exporter,
 it does not need to export an additional x.509 certificate. 
 And I will replace *recommended* with *may*.

In this section, Brian suggested entire descriptions, as follows.
I will improve according to it. Thank you, Brian. 
In Section 9.3, your question about exporting "Certification" is described.

9.  Security Considerations 

   As they act as both IPFIX Collecting Processes and Exporting
   Processes, the Security Considerations for IPFIX [RFC5101] apply as
   well to Mediators.  The Security Considerations for IPFIX Files
   [RFC5655] apply as well to IPFIX Mediators that write IPFIX Files or
   use them for internal storage.  However, there are a few specific
   considerations that IPFIX Mediator implementations must take into
   account in addition.

   By design, IPFIX Mediators are "men-in-the-middle": they intercede in
   the communication between an Original Exporter (or another upstream
   Mediator) and a downstream Collecting Process.  TLS provides no way
   to connect the session between the Mediator and the Original Exporter
   to the session between the Mediator and the downstream Collecting
   Process; indeed, this is by design.  This has important implications
   for the level of confidentiality provided across an IPFIX Mediator,
   and the ability to protect data integrity and Original Exporter
   authenticity across a Mediator.  In general, a Mediator SHOULD
   maintain the same level of integrity and confidentiality protection
   on both sides of the mediation operation, except in situations where
   the Mediator is explicitly deployed as a gateway between trusted and
   untrusted networks.

   Subsequent subsections deal with specific security issues raised by
   mediation.

9.1.  Avoiding Security Level Downgrade

   An IPFIX Mediator that accepts IPFIX Messages over a Transport
   Session protected by TLS or DTLS, and which then exports IPFIX
   Messages derived therefrom in cleartext, is a potentially serious
   vulnerability in an IPFIX infrastructure.

   An IPFIX Mediator MAY export records derived from protected records
   in cleartext, but only in the case that it acts as a proxy between an
   external (untrusted) network and an internal (trusted) network, when
   the path to the downstream collector is on a physically protected,
   separated network (e.g., in the same locked equipment rack) such that
   the additional overhead of a TLS session is unnecessary.

   In other words, an IPFIX Mediator that receives IPFIX Messages from
   an upstream Exporting Process protected using TLS or DTLS MUST
   provide for sending of IPFIX Messages resulting from the operation of
   the Intermediate Process(es) to a downstream Collecting Process using
   TLS or DTLS.  It MAY allow for the configuration of unprotected
   export of such IPFIX Messages, but in this case it MUST warn the
   administrator that the exported IPFIX Messages will not be protected,
   and that this could result in the leakage of information deemed by
   the Original Exporter to be worth protecting.

9.2.  Avoiding Security Level Downgrade

   There is a similar problem in the opposite direction: as an IPFIX
   Mediator's signature on a TLS session to a downstream Collecting
   Process acts as an implicit assertion of the trustworthiness of the
   data within the session, a poorly deployed IPFIX Mediator could be
   used to "legitimize" records derived from untrusted sources.
   Unprotected sessions from the Original Exporter are in the general
   case untrusted, because they could have been tampered with or forged
   by an unauthorized third party.

   An IPFIX Mediator MAY export signed Messgaes containing records
   derived from records received in cleartext, but only in the case that
   it acts as a proxy between an internal (trusted) and an external
   (untrusted) network, when the path from the Original Exporter is on a
   physically protected, separated network, such that the additional
   overhead of an TLS session is unnecessary.

   In other words, an IPFIX Mediator that receives IPFIX Messages from
   an upstream Exporting Process in cleartext MUST default to sending
   IPFIX Messages resulting from the operation of the Intermediate
   Process(es) to the downstream Collecting Process in cleartext.  It
   SHOULD allow for the configuration of export of such IPFIX Messages
   protected by TLS or DTLS, but in this case it MUST warn the
   administrator that the exported IPFIX Messages will be signed as
   trusted by the Mediator, and that this could result in downstream
   Collecting Process trusting data derived from unprotected sources.

9.3.  Approximating End-to-End Assertions for Mediators

   Because the Transport Session between an IPFIX Mediator and an
   Original Exporter is independent from the Transport Session between
   the Mediator and the downstream Collecting Process, there exists no
   method via TLS to assert the identity of the original Exporting
   Process downstream.  However, an IPFIX Mediator, which modifies the
   stream of IPFIX Messages sent to it, is by definition a trusted
   entity in the infrastructure.  Therefore, the IPFIX Mediator's
   signature on an outgoing Transport Session can be treated as an
   implicit assertion that the Original Exporter was positively
   identified by the Mediator and that the source information it
   received was trustworthy.  However, IPFIX Mediators must in this
   circumstance take care not to provide an inappropriate upgrade of
   trust.

   Therefore, an IPFIX Mediator SHOULD NOT sign a Transport Session to a
   downstream Collector unless ALL the Original Exporters from which the
   information to be exported is derived were positively identified by
   the Mediator by its certificate.  An exception to this case is the
   reverse of the special case in the previous subsection: an IPFIX
   Mediator that accepts information from within a trusted domain via an
   internal network protected by other means MAY use TLS or DTLS to
   protect the Transport Session to a downstream Collector outside the
   domain.

   If the X.509 certificates used to protect a Transport Session between
   an Original Exporter and an IPFIX Mediator are required downstream,
   an IPFIX Mediator MAY use the exporterCertificate and the
   collectorCertificate Information Elements with the Export Session
   Details Options Template defined in Section 8.1.3 of [RFC5655] or the
   Message Details Options Template defined in Section 8.1.4 of
   [RFC5655] in order to export this information downstream.  However,
   in this case, the IPFIX Mediator is making an implicit assertion that
   the upstream Session was properly protected and therefore
   trustworthy, and as such MUST protect the Transport Session to the
   downstream Collector using TLS or DTLS, as well.

9.4.  Multiple Tenancy

   An IPFIX Mediator handling traffic data from multiple separate
   sources or for multiple separate purposes MUST provide for keeping
   these data separate.  Though the details of this are application-
   specific, this generally entails separating Transport Sessions within
   the Mediator, and associating them with information related to the
   source or purpose, e.g., network or hardware address range, virtual
   LAN tag, interface identifiers, and so on.  Information from multiple
   sources MAY only be combined within a Mediator when that Mediator is
   applied for that specific purpose (e.g., aggregation or concentration
   of records).

9.5.  Configuration Protection

   Due to their trusted position within the infrastructure, Mediators
   MUST provide for the protection of their configuration information,
   requiring positive authentication and authorization of administrators
   for configuration tasks.

> All in all, I'm very happy with the draft and excited to see how, after 
> five years, it now smoothly integrates all of our different ideas on 
> correlation, aggregation, and anonymization. Thanks for all your hard work!
> 

Thank you very much. I appreciate your contribution.

Regards,

Atsushi

> 
> Best regards,
> 
>    Christoph
> 
> -- 
> Christoph Sommer
> Dept. of Electrical and Computer Eng.
> Carnegie Mellon University, Pittsburgh, PA
> Phone: +1 412 268-4212 / Fax: +1 412 268-2860
> http://www.andrew.cmu.edu/~csommer/
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix
> 

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