Requirements for IP Flow Information Export (IPFIX)
draft-ietf-ipfix-reqs-16

[Ballot discuss]
Some of my discuss comments were addressed in the -15 version. Thanks!
However, I still have the following outstanding issues that have not been
fully resolved:

  Many requirements in this document are not explicitly stated as IPFIX
  protocol requirements, but as requirements for the metering process,
  the exporting process, or for other traffic measurement components.
  However, every requirement that needs support from the IPFIX protocol
  MUST be covered by the IPFIX protocol specification and related
  standard documents independent of the significance of the
  requirement, which can be MANDATORY (MUST), RECOMMENDED (SHOULD), or
  OPTIONAL (MAY).

>> This doesn't make any sense to me.  If these are the requirements
>> for a protocol, then what does it mean to say that a requirement
>> is OPTIONAL (MAY)?  That it MUST be supported by the protocol?

Although the word "MANDATORY" was changed to "REQUIRED" in this section, that does not answer my question.  What does this section mean?  At least one interpretation of this section is that everything listed in this document MUST be included in the IPFIX protocol, even if this document says that the feature is OPTIONAL (or MAY be supported).  So, what is the value/significance of using different requirements levels if everything is really a MUST?

Also, if I'm understanding the intent correctly, then this section disagrees with the section that says that these terms will be used as defined in RFC 2119...

4.2.  IP Header Fields

  The metering process MUST, SHOULD, or MAY be able to separate flows
  by the following fields of the IP header as indicated.

>> Editorial comment:  There are no "MAYs" in the list.

      1. source IP address (MUST)

      2. destination IP address (MUST)

      3. protocol type (TCP,UDP,ICMP,...) (MUST)

      4. IP version number (SHOULD)
        This requirement only applies if the observation point is
        located at a device that is supporting more than IP version.

  For source address and destination address, separating by full match
  MUST be supported as well as separation by prefix match.

>> Shouldn't you be able to identify a flow based on the IPv6
>> Flow ID?

I still don't understand why you would not be able to separate flows using the IPv6 flow ID.  The whole point of the IPv6 Flow ID (as I understand it) is to allow for separation of flows in a more efficient manner in cases where the protocol types may not be in a fixed location in the packet.  Also, it will work in cases where the higher-level protocols are encrypted.  Could someone please explain to me why we would not want this ability in a flow export protocol?


4.5.  DiffServ Code Point

  If the observation point is located at a device supporting
  Differentiated Services (DiffServ) then the metering process MUST be
  able to separate flows by the DiffServ Code Point (DSCP, see
  [RFC2474]).

>> Why isn't this listed as an IP header field?  And why do you
>> want to be able to identify flows based on the DSCP, but not
>> the full traffic class?

I am still not sure why this is listed in a separate section, rather than as an IP header field.  Also, I don't understand why you would only want to be able to separate flows based on the DSCP, not the full traffic class.

[Note]: 'New revision (13) has been submitted. See ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-13.txt untill it shows up in repository. I picked this one up from Randy. It was on IESG agenda in APril 2003. Supposedly this new rev has addressed conerns. But since it has been such a long time, I think it would be good that ADs (specifically those who reaised issues in APril) check it again.' has been cleared by Bert Wijnen

[Note]: 'New revision (13) has been submitted. See ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-13.txt untill it shows up in repository. I picked this one up from Randy. It was on IESG agenda in APril 2003. Supposedly this new rev has addressed conerns. But since it has been such a long time, I think it would be good that ADs (specifically those who reaised issues in APril) check it again.' added by Amy Vezza

[Ballot discuss]
I have included my specific comments on this document below.  In
general, I think it is a reasonable document, but I have a couple
of concerns that I think should be addressed before publication:

(1) I don't understand the section that discusses the significance
    of how the terms MUST, SHOULD or MAY are used in this document.

(2) The list of information that an exporting process must be
    able to report in section 6.1 includes several items that
    may not be constant for a given flow, given the definition 
    of "flow" in this document, so it isn't clear how they can
    be reported for all flows.

More details and a few editorial comments are included below:

  Many requirements in this document are not explicitly stated as IPFIX
  protocol requirements, but as requirements for the metering process,
  the exporting process, or for other traffic measurement components.
  However, every requirement that needs support from the IPFIX protocol
  MUST be covered by the IPFIX protocol specification and related
  standard documents independent of the significance of the
  requirement, which can be MANDATORY (MUST), RECOMMENDED (SHOULD), or
  OPTIONAL (MAY).

>> This doesn't make any sense to me.  If these are the requirements
>> for a protocol, then what does it mean to say that a requirement
>> is OPTIONAL (MAY)?  That it MUST be supported by the protocol?

4.2.  IP Header Fields

  The metering process MUST, SHOULD, or MAY be able to separate flows
  by the following fields of the IP header as indicated.

>> Editorial comment:  There are no "MAYs" in the list.

      1. source IP address (MUST)

      2. destination IP address (MUST)

      3. protocol type (TCP,UDP,ICMP,...) (MUST)

      4. IP version number (SHOULD)
        This requirement only applies if the observation point is
        located at a device that is supporting more than IP version.

  For source address and destination address, separating by full match
  MUST be supported as well as separation by prefix match.

>> Shouldn't you be able to identify a flow based on the IPv6
>> Flow ID?

4.5.  DiffServ Code Point

  If the observation point is located at a device supporting
  Differentiated Services (DiffServ) then the metering process MUST be
  able to separate flows by the DiffServ Code Point (DSCP, see
  [RFC2474]).

>> Why isn't this listed as an IP header field?  And why do you
>> want to be able to identify flows based on the DSCP, but not
>> the full traffic class?

  The exporting process MUST be able to report the following attributes
  for each metered flow:

      1. IP version number
        This requirement only applies if the observation point is
        located at a device supporting more than one version of IP.

>> How is a device that requests flow information supposed to know
>> whether or not the observation point supports more than one
>> version of IP? 

      2. source IP address
      3. destination IP address
      4. IP protocol type (TCP,UDP,ICMP,...)
      5. if protocol type is TCP or UDP: source TCP/UDP port number
      6. if protocol type is TCP or UDP: destination TCP/UDP port number
      7. packet counter
        If a packet is fragmented, each fragment is counted as an
        individual packet.
      8. byte counter
        The sum of the total length in bytes of all IP packets
        belonging to the flow.  The total length of a packet covers IP
        header and IP payload.
      9. type of service octet (in case of IPv4), traffic class
        octet (in case of IPv6).  According to RFC 2474 these octets
        include the DiffServ Code Point that has a length of 6 bits.
    10. in case of IPv6: Flow Label
    11. if MPLS is supported at the observation point: the top MPLS
        label or the corresponding forwarding equivalence class (FEC,
        [RFC3031]) bound to that label.  The FEC is typically defined
        by an IP prefix.
    12. timestamp of the first packet of the flow
    13. timestamp of the last packet of the flow
    14. if sampling is used: sampling configuration
    15. unique identifier of the observation point
    16. unique identifier of the exporting process

>> Is it assumed that these values will be constant for any
>> captured flow?  This isn't consistent with the definition
>> of "flow" used in this document.  As an example, if a flow
>> is defined as all traffic between two IP addresses, the
>> items 4, 5, 6, 9, 10 and 11 may not be constant.

10.  Security Considerations

  An IPFIX protocol must be capable to transport data over the public

>> Editorial: s/capable to transport/capable of transporting

  Internet.  Therefore it cannot be excluded that an attacker captures
  or modifies packets or inserts additional packets.

[Ballot comment]
Minor comment: I think it would be useful to move section 4.6 up, so that the note
relating to encrypted header fields occurs before the requirements which cannot be met for
encrypted header fields

[Ballot discuss]
My comments from 2003-04-03 were addressed, but one of themin a confusing
way.  I believe that these comments are pretty minor.  Hopefully they
can be addressed much more quickly than the previous ones.

  In section 6.3.3, the difference between 'specific data' and 'IPFIX
  data' is not clear to me.
 
  In section 12, the large table includes this row:
 
    | Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
    |-------+-------------------------+-----+-----+-----+-----+-----+------|
    | 6.3.3.| Confidentiality        |  M  |  S  |  S  |  S  |  S  |  M  |
    |-------+-------------------------+-----+-----+-----+-----+-----+------|

  I believe that the discussion in section 10 indicates that column D
  ought to contain 'M' instead of 'S'.

[Ballot comment]
I find the structure of section 4.2 very awkward.  There has to be a
  better way to say the same thing.  Also, there are no MAY requirements
  in the list that follows the introductory sentence.

  In section 4.6, the document acknowledges that some header fields may
  not be available if encryption is used.  I think the placement of this
  text would be better in the introduction to section 4.  the resulting
  section would say: unless the use of security protocol that provides
  encryption prevents the gathering of of the following information, then
  the solution MUST ....

  In section 10.1: s/spy out/spy on/

[Ballot discuss]
My comments from 2003-04-03 were addressed, but one of themin a confusing
way.  I believe that these comments are pretty minor.  Hopefully they
can be addressed much more quickly than the previous ones.

  1. I find the structure of section 4.2 very awkward.  There has to be a
  better way to say the same thing.  Also, there are no MAY requirements
  in the list that follows the introductory sentence.

  2. In section 4.6, the document acknowledges that some header fields may
  not be available if encryption is used.  I think the placement of this
  text would be better in the introduction to section 4.  the resulting
  section would say: unless the use of security protocol that provides
  encryption prevents the gathering of of the following information, then
  the solution MUST ....

  3. In section 6.3.3, the difference between 'specific data' and 'IPFIX
  data' is not clear to me.
 
  4. In section 10.1: s/spy out/spy on/

  5. In section 12, the large table includes this row:
 
    | Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
    |-------+-------------------------+-----+-----+-----+-----+-----+------|
    | 6.3.3.| Confidentiality        |  M  |  S  |  S  |  S  |  S  |  M  |
    |-------+-------------------------+-----+-----+-----+-----+-----+------|

  I believe that the discussion in section 10 indicates that column D
  ought to contain 'M' instead of 'S'.

[Ballot comment]
My comments from 2003-04-03 were addressed, but one of themin a confusing
way.  I believe that these comments are pretty minor.  Hopefully they
can be addressed much more quickly than the previous ones.

  1. I find the structure of section 4.2 very awkward.  There has to be a
  better way to say the same thing.  Also, there are no MAY requirements
  in the list that follows the introductory sentence.

  2. In section 4.6, the document acknowledges that some header fields may
  not be available if encryption is used.  I think the placement of this
  text would be better in the introduction to section 4.  the resulting
  section would say: unless the use of security protocol that provides
  encryption prevents the gathering of of the following information, then
  the solution MUST ....

  3. In section 6.3.3, the difference between 'specific data' and 'IPFIX
  data' is not clear to me.
 
  4. In section 10.1: s/spy out/spy on/

  5. In section 12, the large table includes this row:
 
    | Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
    |-------+-------------------------+-----+-----+-----+-----+-----+------|
    | 6.3.3.| Confidentiality        |  M  |  S  |  S  |  S  |  S  |  M  |
    |-------+-------------------------+-----+-----+-----+-----+-----+------|

  I believe that the discussion in section 10 indicates that column D
  ought to contain 'M' instead of 'S'.

[Ballot comment]
The  -13 revision has addressed the concerns on anonymization, congestion avoidance and retransmission I expressed about earlier drafts, all of which were passed on to the ipfix mailing list.

[Note]: 'New revision (13) has been submitted. See ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-13.txt untill it shows up in repository.

I picked this one up from Randy. It was on IESG agenda in APril 2003. Supposedly this new rev has addressed conerns. But since it has been such a long time, I think it would be good that ADs (specifically those who reaised issues in APril) check it again.' added by Bert Wijnen

Date: Fri, 13 Jun 2003 06:43:38 +1200
From: Nevil Brownlee
To: Randy Bush
Cc: Juergen Quittek ,
  Dave Plonka
, nevil@auckland.ac.nz
Subject: IPFIX: Requirements draft back to IESG


Hi Randy:

Juergen Quittek has published a new version of the IPFIX requirements draft,
draft-ietf-ipfix-reqs-10.txt.  The changes between the -09 version and
this one have been made in repsonse to the questions raised by IESG,
they've all been discussed - and consensus reached - on the IPFIX list.

Would you please move this draft gently back to IESG?

Thanks, Nevil

PS: Juergen may have already asked you this, I'm just making sure the
    message gets through!

-----------------------------------------------------------------------


To: Nevil Brownlee
Cc: Juergen Quittek ,
    Dave Plonka
From: Randy Bush
Date: Thu, 12 Jun 2003 19:22:34 -0700
Subject: Re: IPFIX: Requirements draft back to IESG

do you really feel that all of the following comments have either
been resolved with the commenter (i have seen no conversations) or
addressed in -10?  the first few i checked still seemed relevant.

...

From: Steve Bellovin
To: iesg-secretary@ietf.org
Subject: draft-ietf-ipfix-reqs-09.txt
Cc: iesg@ietf.org
Date: Thu, 03 Apr 2003 00:27:47 -0500

4.2(4) What about link-layer distinguisher of IP version?

4.3 What about SCTP?

4.4, 4.5, and others:  This document can't say "If the observation point is
located at a foo".  At most, it can say "a foo-capable box MUST" or "a
box SHOULD do such-and-such so that it can be located at a foo".

4.6 strikes me as dubious for compression.

What about the IPv6 Flow Label as a flow separator?



From: "Wijnen, Bert (Bert)"
To: "Randy Bush (E-mail)"
Cc: "Iesg (E-mail)"
Subject: draft-ietf-ipfix-reqs-09.txt
Date: Thu, 3 Apr 2003 17:34:55 +0200

I see:
  5.4.  Timestamps

    The metering process MUST be able to generate timestamps for the
    first and the last observation of a packet of a flow at the
    observation point. The timestamp resolution MUST be at least the one
    of the sysUpTime [RFC1213], which is one centisecond.

I think I'd rather see a reference to RFC3418 instead of RFC1213.
We can do so by RFC-Editor note. May want to check with authors too.

On page 14 I see:


      9. type of service octet (in case of IPv4), traffic class
        octet (in case of IPv6)
   
Is that not better state as

      9. DSCP, which is set in the type of service octet (in case of IPv4),
        or in the traffic class octet (in case of IPv6)

I ask this, cause for one of my MIB documents I asked Erik Nordmark who
responded:
> If the MIB does v4 and v6 it would make sense to calls this
> DSCP and have it apply across both.
> Also, I think it should be explicitly restricted to the DSCP bits and
> not be able to filter on the ECN bits - too high risk that
> somebody could
> accidentially break ECN.
>
> I hope they are not assuming the old IPv4 ToS definitions.
>

Thanks,
Bert



Date: Thu, 03 Apr 2003 10:37:31 -0500
To: iesg@ietf.org
From: Russ Housley
Subject: draft-ietf-ipfix-reqs-09.txt

I have a few comments on draft-ietf-ipfix-reqs-09.

  I would prefer to see the paragraph referencing RFC 2119 in section 2.

  Last paragraph in section 6.3.3 needs to be reworded.

  In section 10.2, an important point is left unsaid.  If the injection of
IPFIX traffic fool the network provided into thinking that a DOS attack is
underway, the countermeasures employed by the network provider may actually
deny service to real customers.

  The appendix needs to be moved up in the document.

Russ


From: Bill Fenner
To: randy@psg.com
Subject: draft-ietf-ipfix-reqs-09.txt
Cc: iesg@ietf.org
Date: Thu, 3 Apr 2003 07:51:09 -0800
Versions: dmail (solaris) 2.5a/makemail 2.9d


Overall, I like it.  A couple of things jumped out at me, though.
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

      8. byte counter
        Which bytes of a packet are counted MUST be defined exactly.

    20. multicast replication factor
        the number of outgoing packets originating from a single 
        incoming multicast packet. This is a dynamic property of   
        multicast flows, that may change over time. For unicast flows 
        it has the constant value 1. The computation of the factor MUST
        be clearly defined.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?


Also, at the end of 6.1 it kind of says "Plus other stuff related
to inter-AS routing if you want".  It's already in the MAY section;
can't they just list some concrete items related to inter-AS
routing as 27, 28, ...?  I don't think it's useful to say what
amounts to "plus anything else that you might feel like adding that
you think is relevant", since that doesn't encourage different
people to make the same choices.

  Bill


To: randy@psg.com
Subject: draft-ietf-ipfix-reqs-09.txt
Cc: iesg@ietf.org
Date: Thu, 03 Apr 2003 08:55:15 -0800
From: Allison Mankin

This is a good document overall.

The applications include usage-based accounting.  They should cite
RFC 2975, and indicate that the particular niche for usage-based
accounting would not be met if reliability was not very high.
Section 5.1 reliability requirements do not meet the needs, nor do
the timestamping of first and last packet of a flow, because the
flow may have been mischaracterized and that is first and last of
different flows.  The way to satisfy this issue is to caveat the
discussion of usage-based accounting with strong words on
reliability that counter the comments on lesser reliability and
more probabilistic techniques for other applications of ipfix.

Requirements on the ipfix implementation - the document is long and
I wonder if the working group really meant the protocol's
confidentiality and anonymization features to be so optional -
SHOULD confidentiality, MAY anonymization.  Just for
implementation.

From: Nevil Brownlee
The 'IPFIX Requirements' Internet Draft has completed its two-week
WG last call, the editor has made minor textual corrections and published
the final version,

  draft-ietf-ipfix-reqs-09.txt

The WG requests IESG to consider it for publication as an Informational RFC.

This completes a WG milestone, set down for April 2003, please update
the WG's milestones list accordingly.