Document: draft-ietf-ipfix-as-08.txt Reviewer: Gray, Eric [Eric.Gray@marconi.com] Review Date: Wednesday 6/21/2006 1:25 PM IETF LC Ends: Thursday, 22 June 2006 Summary: This document is almost ready for publishing as an Informational RFC. Below, I have listed several minor (mostly editorial) comments, and about the same number of NITs, that I would like to see addressed. Comments/Observations/Questions: =============================== In section 2.3 ("Traffic Engineering"), I am not sure that methods you suggest will let an application determine "link utilization" except for physical links associated with physical interfaces. If you agree that this is a limitation, is it worth stating this in this section? --------------------------------------------------------------------- In section 2.4, 4th paragraph (2nd paragraph on page 9), a sudden increase of flows from different sources to a specific destination may also be an indication of a DDoS attack, or some specific event. It might be worth mentioning at least the DDoS attack possibility. You do - in the next paragraph - mention the "event" possibility. Also, in this same paragraph, references to TCP-FIN/TCP-SYN and Worm "signatures" are orders of magnitude more difficult to recognize than simple changes in flow volumes. Perhaps these should be discussed in more detail, or at least made into a separate paragraph? --------------------------------------------------------------------- In the second paragraph on page 10, what does the first sentence mean? It says: "Detecting security incidents in real-time often requires the pre-processing of data already at the measurement device." --------------------------------------------------------------------- In the last sentence (bullet under "Remarks") before section 2.5.2.2 - the characteristic (or property) "granularity" is not modifiable by adjectives such as "higher" or "lower". If you want to say "finer granularity" or "coarser granularity", then please say it that way. The same comment applies to the 1st bullet on page 13. A similar observation may apply to the use of "higher" as a modifier to "threats" in the first paragraph of section 2.6 ("higher risks" or "higher threat-levels" makes more sense - in this context - than "higher threats"). --------------------------------------------------------------------- In section 2.5.2.2, you should mention (or refer to a document that identifies concerns, or methods of addressing) the need to eliminate or compensate for measured-time differences at multiple locations in computing one-way delay. Packet transport times are usually on a time-scale at which likely differences in local times can be quite significant (especially if you are expecting to obtain delay values accurate in nanoseconds). --------------------------------------------------------------------- There are PSAMP reference in section 3.1, RMON references in section 3.2, AAA references in section 3.4 and RTFM in section 3.5 - but no references for IPPM in section 3.3. Can we add one or more references in this section, or are they all implied by references in sections 2.5 and 2.7? --------------------------------------------------------------------- Who is "They" in the second paragraph on page 17 (toward the middle of the paragraph)? Is it the AAA functions, or the combination of IPFIX collection and AAA functions? --------------------------------------------------------------------- Are there really no plans, or work in progress, to define remote configuration for IPFIX? This is particularly irksome in light of the last paragraph in section 4.3 - "Whether [arrival of more records than the receiving application can process] is a relevant drawback depends on the flexibility of the IPFIX configuration and how IPFIX configuration rules are implemented." But this is just one issue with not defining (or at least planning to define) a remote configuration standard for IPFIX. Another is that - if it is necessary (or even just useful), and not defined as a standard - then it will very likely have to be defined as vendor proprietary several times. --------------------------------------------------------------------- Section 5 ("Security Considerations") provides a severe example of a minor misuse of the terms "framework" and "architecture" - it is difficult to use IPFIX in combination with "other frameworks" as it is not clear what it means to "use a framework." I suggest replacing "framework" - at least - and maybe "architecture" with "technology" (or "technologies") where it seems appropriate. In this section, for example, the first sentence in the second paragraph makes more sense as: "Section 3 of this document describes how IPFIX can be used in combination with other technologies." Using IPFIX with another framework is somewhat between this and using IPFIX in a different frame of reference - which is one of the things covered in section 4. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NITs: ==== ** Second sentence in the introduction: "It is intended to provide this information as input to various applications." Because the intent of this document is to define when/where IPFIX might be useful, I would suggest rewording this sentence as: "IP Flow information can be used as input to various applications." -------------------------------------------------------------------- ** Fourth sentence in the introduction: "This document describes how typical applications that can use the IPFIX protocol." I assume you're trying to say this: "This document describes how typical applications can use the IPFIX protocol." (That is what you say in a subsequent paragraph) -------------------------------------------------------------------- ** In section 2.1, after the second sentence: I believe you meant the next sentence to start a new paragraph. This seems to happen in several sections (sections 2.3, 2.5.1 and 3.2 are other examples, where a 2nd paragraph is "bunched up" with the 1st - although, in section 3.2, all of the paragraphs are "bunched up" and this appears to be the case in section 3.5.1 as well). In general, there are too many cases of paragraph "bunching" to list them all in this review. --------------------------------------------------------------------- ** In section 2.1.1: RFC 3330 is Informational; as such it does not "demand" or "require" anything. The "Please note" at the beginning of section 2.1.1 should be reworded similar to as follows: "As noted in [RFC3330], the address block 192.0.2.0/24 may be used for example addresses." -------------------------------------------------------------------- ** Bottom of page 5, top of page 6: It is usually a good idea (for readability) to keep blocks like this (template set) together. -------------------------------------------------------------------- ** Section 2.3, 2nd (or 3rd?) paragraph: The parenthesized phrase "as usually the case" should be either simply "usually the case" or "as is usually the case". --------------------------------------------------------------------- ** Next to last paragraph on page 9: "IPIFX" should be "IPFIX". (Same applies to the 2nd paragraph on page 10, the last one on page 11, and the 1st and 3rd paragraphs on page 15.) --------------------------------------------------------------------- ** Section 4.3, 3rd paragraph, 1st sentence: The phrase "as certain thresholds are about to exceed" should be something like "as certain thresholds are about to be exceeded."