Re: [IPFIX] WGLC comments on draft-ietf-ipfix-mediators-problem-statement-06

[Keisuke ISHIBASHI <ishibashi.keisuke at lab.ntt.co.jp>]

Hi all, 

Although it's about specific mediator devices, I'm bit uncertain of
the hierachical collection system built with IPFIX Concentrators in
Section 5.2. 
If the Cocentrators only aggregate the flow records from original
Exporters, then, from the Collector's point of view, there is no
difference from the case that the original Exporters gererate
aggregated flow records. I don't have a image that this type of
mediator provide a solution to the problem stated in Section 4.1.
What about an example that those Concentrators have retention
capabilities of original Flow Records, as follow:

      To cope with the increase of IPFIX Exporters and traffic, one
      possible implementation uses IPFIX Concentrators with Collecting
      Process to build a hierarchical collection system. 

, which is similar to the last implementation example in Section 5.7. 
This is a very minor comment, however, I'm willing to go on as they
are.

> The Security Considerations section is a little week; I suspect the  
> IESG in particular will require a more in-depth analysis of Mediator- 
> specific attacks. 

Yes, for example, weakening of the trust chain by supporting legacy
protocols may be one of the above case?

Best regards,
Keisuke ISHIBASHI
NTT Information Sharing Platform Labs.


From: Brian Trammell <trammell at tik.ee.ethz.ch>
Subject: [IPFIX] WGLC comments on
	draft-ietf-ipfix-mediators-problem-statement-06
Date: Tue, 27 Oct 2009 11:16:05 +0100
Message-ID: <E51D1CD9-765F-44CB-B9B2-35F285FD4CCD at tik.ee.ethz.ch>

> Greetings, all,
> 
> Please find below my WGLC comments on the Mediator PS draft.
> 
> The Implementation Analyses in Section 5.x are in my opinion still too  
> tied to specific mediator devices. We're talking about Concentrators  
> and Masquerading Proxies and Distributors as if there was a  
> substantive difference among them. There isn't. There are Mediators.  
> They run Intermediate Functions. They accept IPFIX, or something like  
> it (e.g. NetFlow). They produce IPFIX. They might change the content  
> or framing based on configuration and state. Drawing more restrictive  
> labeled boxes around specific types of intermediate functions risks  
> limiting flexibility and provides the impression that complicated  
> mediation might require multiple devices.
> 
> However, we've had this discussion for a very long time without coming  
> to agreement, and it's a relatively minor point, so I'm willing to let  
> these sections go as they are. However, I will state that I find the  
> Intermediate Process and Mediator definitions in the Terminology to be  
> quite useful (as they should be considering the amount of work we put  
> into them before and during the Stockholm meeting :) ), but the  
> others, not so much.
> 
> The Security Considerations section is a little week; I suspect the  
> IESG in particular will require a more in-depth analysis of Mediator- 
> specific attacks. Mitigation could, of course, also be handled in the  
> Mediator Protocol draft. One thing that came up in the 5655 review is  
> the issue of chains of trust, so I suspect there will also be  
> questions about how a final collector will be able to authenticate an  
> Original Exporter across a Mediator. But these can be handled at the  
> IESG stage.
> 
> (Also, one very minor nit, in the Acknowledgments sections, my last  
> name is spelled Trammell.)
> 
> Best regards,
> 
> Brian
> _______________________________________________
> IPFIX mailing list
> IPFIX at ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix