IP Flow Information Export (IPFIX) Applicability
draft-ietf-ipfix-as-12

[Ballot discuss]
From the Gen-ART Review by Eric Gray.

  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.
  >
  Please add clarifying text.

[Ballot discuss]
Section 2.1 first mentions that IPFIX cannot comply with the
reliability requirements of RFC 2975. But then it continues
to talk about proper configuration of IPFIX for a given
tariff system.

It is unclear to me if unreliable accounting can be
combined with usage based billing at all. As a
result, I am uncomfortable with the discussion of
tariff systems in this document, and would prefer to
see the document not focus on billing or rating.

This may require changes in Section 2.1.

> As shown in section 2.1 accounting applications can directly
> incorporate an IPFIX collecting process to receive IPFIX records
> with information about the transmitted volume. Nevertheless, if
> an AAA infrastructure is in place, the cooperation between IPFIX
> (and especially IPFIX with reliability extensions) and AAA
> provides many valuable synergistic benefits. IPFIX records can
> provide the input for AAA accounting functions and provide the
> basis for the generation of DIAMETER accounting records. 

I am not sure I follow. If we turn unreliable data stream
into a reliable protocol, it does not make the entire system
reliable. I would suggesting adding this sentence at the
end: "However, such input can only be used situations where
the purpose of the accounting does not require reliability."

> Sharing IPFIX records (either directly or
> encapsulated in DIAMETER) with neighbor providers allows an
> efficient inter-domain attack detection.

Perhaps, but many details are missing. For instance,
the document appears to assume that mere delivery
of records is sufficient. However, in any large
provider setting, it would be very hard to process
all traffic flow records of all clients at all
times, even when they are roaming from another
network. As a result, there may be a need to
provider finer-grain control of what is measured,
for who, and when. Perhaps the document could
point out that further work may be needed.
It seems to be needed in any case, since no
IPFIX record AVPs have been defined for
AAA protocols, AFAIK. This should also be pointed
out, or alternatively the relevant documents
where they are defined should be referred.

[Ballot comment]
The document talks a lot about what IPFIX and other working groups did
and didn't do. Given that working groups are ephemeral, it would be better
to rephrase things such the text is about the RFCs that are out there, rather
than the groups that have produced them.

[Note]: 'waiting for release 08 at the request of the WG chairs and editors of the document befroe going to IETF LC' added by Dan Romascanu

AD review posted to WG list.

Waiting for WG (chairs) to respond to the review

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Wijnen, Bert (Bert)
Sent: Friday, March 17, 2006 18:34
To: 'Ipfix Wg' (E-mail) (E-mail)
Cc: Dan Romascanu (E-mail); David Kessens (E-mail)
Subject: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt


Sorry for the long delay.

Overall question:

  Is this a document to describe realistic applicability of IPFIX,

  or

  Is it more of a marketing or promitional document to try and
  push itinto all sorts of existing systems?

This is the first time I read this document, and I did find myself
wondering several times if I was reading promotional material to
convince me of all sorts of places where I could go use this.
In many scenarios it would mean extending the Information Model,
so it is not as if it would be a no-effort activity.

As an AD I woner if the other groups have all looked at the
scenarios that would touch or interact on their turf so to speak.
Like has WGs like IPPM, AAA, IDMEF, RMONMIB, RTP etc looked at this?
It seems there might be quite a set of questions from there.

And then there is the question if operators really want IPFIX to
be interacting/integrating with all these other areas. Maybe they
do. Have you (WG) proof of that or expressions of support from
operators?

So I am not yet how to move ahead with this one.
It is targeted for Informational, so we have some leverage.
But I'd like to have some answers on the above first.

Meanwhile, below are some nits to look at:

- IPv4 sample addresses should be from the range 192.0.2.0/24 as
  per RFC3330. So you better update the addresses on page 6.

- the last sentence on page 7 spaking about PSAMP seems
  a bit out of place in the middle of a discussion of
  using IPFIX for IDS.

- citation/reference issues
  those with a - in the middle might be OK, my tool does not (yet)
  recognize linebreak at such points.

  !! Missing citation for Informative reference:
  P021 L046:    [DuGr00]      Nick Duffield, Matthias Grossglauser, "Trajectory

  !! Missing citation for Informative reference:
  P021 L051:    [GrDM98]      Ian D. Graham, Stephen F. Donnelly, Stele Martin,

  !! Missing Reference for citation: [PSAMP-FM]
  P018 L012:    requirements in [PSAMP-FM] that directly affect the export

  !! Missing Reference for citation: [PSAMP-PROTOCOL]
  P018 L013:    protocol. In [PSAMP-PROTOCOL] the requirements have been

  !! Missing citation for Informative reference:
  P022 L012:    [PSAMP-FW]    Nick Duffield (Ed.), "A Framework for Packet

  !! Missing citation for Informative reference:
  P022 L051:    [RFC3577]    S. Waldbusser, R. Cole, C. Kalbfleisch,


Bert