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

From: Atsushi Kobayashi <[email-masked]>
Date: Tue, 03 Nov 2009 02:52:01 +0900

Hi Brian, all,

Thank you for the review.

On Tue, 27 Oct 2009 11:16:05 +0100
Brian Trammell <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

-- 
Atsushi Kobayashi <[email-masked]>

---

From: Atsushi Kobayashi <[email-masked]>
Date: Tue, 03 Nov 2009 02:59:32 +0900

Hi Ishibashi-san,

On Wed, 28 Oct 2009 09:27:28 +0900 (JST)
Keisuke ISHIBASHI <[email-masked]> wrote:

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

It's fine with me.

> , 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.
> 
> > specific attacks. 
> Yes, for example, weakening of the trust chain by supporting legacy
> protocols may be one of the above case?
> 

Could you please see my proposal in another mail.

Regards,
Atsushi

> Best regards,
> Keisuke ISHIBASHI
> NTT Information Sharing Platform Labs.
> 
> 
> From: Brian Trammell <[email-masked]>
> Subject: [IPFIX] WGLC comments on
> 	draft-ietf-ipfix-mediators-problem-statement-06
> Date: Tue, 27 Oct 2009 11:16:05 +0100
> Message-ID: <[email-masked]>
> 
> > Greetings, all,
> >

---

From: Brian Trammell <[email-masked]>
Date: Wed, 4 Nov 2009 10:30:30 +0100

hi Atsushi,

replies as always inline...

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

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

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.

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.

>> name is spelled Trammell.)

No problem. :) I lose the second 'L' about a quarter of the time.

Best regards,

Brian

---

From: Atsushi Kobayashi <[email-masked]>
Date: Thu, 05 Nov 2009 02:07:52 +0900

Hi Brian,

On Wed, 4 Nov 2009 10:30:30 +0100

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

> mediators is a general case of this.

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

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

> of actually making this consistent to the later draft.

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

> No problem. :) I lose the second 'L' about a quarter of the time.

I'm looking forward to meeting you at Hiroshima.

Regards,
Atsushi

> Brian

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