Subject: [ipfix] IESG comments on: draft-ietf-ipfix-reqs-13.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 9 Jan 2004 16:12:44 +0100

The IESG discussed your document on our bi-weekly telechat 
yesterday. The results are below. You can also see them
in the ID-tracker.

In general, a DISCUSS statement needs to be fixed or we need to
give a proper answer/explanation why what we have is OK.

A COMMENT statement describes things that IESG memebers noticed 
while reviewing and could be improved. So if we do a change to
address the DISCUSSes (from Margaret and Russ), then we might
as well try to address as much COMMENTs as we can.

I hope we can do a quick revision and do not need another
6-8 months since the last time it appeared on the IESG
agenda. 

Thanks,
Bert 
-------------- IESG DISCUSSes and COMMENTs ---------
Steve Bellovin:
Comment:
4.2(4) doesn't parse.

Ned Freed:
Comment:
Nit: No IPR boilerplate

Security considerations section here is IMO very nice.

Ted Hardie:
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

Russ Housley:
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'.

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/

Allison Mankin:
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.

Margaret Wasserman:
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.

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/