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

[Atsushi Kobayashi <akoba at nttv6.net>]

Hi Brian, all,

Thank you for the review.

On Tue, 27 Oct 2009 11:16:05 +0100
Brian Trammell <trammell at tik.ee.ethz.ch> wrote:

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

To state the applicability of mediator, it would be preferable to
mention more concrete device and specific scenario. 
Although we can replace all of specific mediator with mediator, but we
should say somewhere what is the difference between mediator and
concentrator/proxy in RFC3917.

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

Thank you for your suggestion. 
Security Considerations section in RFC 5655 could be applied to
Exporter-Mediator-Collector structure. I would add the following 
paragraph by its reference, is it fine?

o  End-to-End Assertions

Note that End-to-End channel that is Exporter-to-Collector via Mediator
channel may be untrusted, even though the Mediator-to-Collector channel
is trusted. When the Mediator-to-Collector channel is trusted and the
Exporter and the Mediator are identified by their certificates,
the Data Records may be implicitly asserted to be trusted.


> (Also, one very minor nit, in the Acknowledgments sections, my last  
> name is spelled Trammell.)
> 

Sorry for that.

Regards,
Atsushi

> Best regards,
> 
> Brian
> _______________________________________________
> IPFIX mailing list
> IPFIX at ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix

-- 
Atsushi Kobayashi <akoba at nttv6.net>