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