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

[Atsushi Kobayashi <akoba at nttv6.net>]

Hi Brian,

On Wed, 4 Nov 2009 10:30:30 +0100
Brian Trammell <trammell at tik.ee.ethz.ch> wrote:

> hi Atsushi,
> 
> replies as always inline...
> 
> On Nov 2, 2009, at 6:52 PM, Atsushi Kobayashi wrote:
> 
> > 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.
> 
> I think a statement in the Terminology section for Mediator could  
> easily state "Note that the Mediator is a generalization of the  
> Concentrator and Proxy elements envisioned in the IPFIX Requirements  
> [RFC3917]; Mediators running appropriate Intermediate Processes  
> provide the functionality specified therein." and then we can dispense  
> with the 3917-legacy language. But only if we want to go that route.  
> At this point, as I said, it's not really important and we've burned  
> enough time on it, so I'm happy letting it go as is.

You and Gerhard share same opinion. If other members including
co-authors agree so, I will try to follow the above suggestion.

> 
> >> 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.
> 
> hm, not exactly... While the problem is analogous, the end-to-end  
> assertion language was a direct reply to a question raised by Sam  
> Hartman about the applicability of an EP->CP->File path for law  
> enforcement applications, where certain chain of evidence requirements  
> are imposed on what the File knows about the EP. The problem with  
> mediators is a general case of this.
> 

If we consider more general case, it is a little bit hard work at this
stage.

> Further, the Collector cannot know a priori that the Mediator got a  
> good certificate from the Exporter. We can use a similar approach to  
> File, and state that a Mediator must not sign a TLS session when the  
> data source was not verified; of course, this breaks the potential use  
> case where a Mediator is used to retransmit non-encrypted UDP messages  
> from a private messages to the open internet over DTLS/SCTP or TLS/ 
> TCP. So we have to be careful there.
> 

Yes, above use case is conceivable. As you mentioned, applicable use
cases and security requirement seem a contradictory argument.

> Actually, on second thought, _solving_ this problem should be done in  
> the Framework, not the Problem Statement. So I'd defer the hard work  
> of actually making this consistent to the later draft.
> 

Ok. Could you please continue to post the relevant suggestion.

> >
> >> (Also, one very minor nit, in the Acknowledgments sections, my last
> >> name is spelled Trammell.)
> >>
> >
> > Sorry for that.
> 
> No problem. :) I lose the second 'L' about a quarter of the time.
> 

I'm looking forward to meeting you at Hiroshima.

Regards,
Atsushi

> Best regards,
> 
> Brian
> 

--- 
Atsushi KOBAYASHI  <akoba at nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637