Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
draft-ietf-ipfix-protocol-26

Note: the reference to draft-ietf-ipfix-architecture is technically a downref (see RFC 3967)

"Specification of the IPFIX Protocol for the Exchange of IP Traffic
Flow Information" would be a better title.

Question: is IANA supposed to create a registry for
IPFIX Version Number or IPFIX Set ID?

Comments from the DNS review team by Ólafur Guðmundsson:

The IPFIX documents are impressive, in size and how well they are written,
I did not have time to think through the protocol but from what I
nothing was sticking out like a sore thumb.

I would suggest that Section 10.3.6, paragraph 2, be added
default values for the rate and number of copies
associated with template changes.

Section 1.1, paragraph 1:

>    The IPFIX protocol provides network administrators with access to IP
>    flow information.  The architecture for the export of measured IP
>    flow information out of an IPFIX exporting process to a collecting
>    process is defined in [IPFIX-ARCH], per the requirements defined in
>    [RFC3917].  This document specifies how IPFIX data record and

  Nit: s/record/records/


Section 2., paragraph 10:

>       1. one or more packet header field (e.g. destination IP address),
>       transport header field (e.g. destination port number), or
>       application header field (e.g. RTP header fields [RFC1889])

  Nit: s/field/fields/ everywhere in this paragraph


Section 10., paragraph 1:

>    The IPFIX Protocol Specification has been designed to be transport
>    protocol independent.  Note that the Exporter can export to multiple
>    Collecting Processes, using independent transport protocols.

  So why do Section 8 and Section 9 talk about specifics when SCTP is
  used? Are the mechanisms described in those sections different for
  other transports?


Section 10.3.3, paragraph 1:

>    The maximum size of exported messages MUST be configured such that
>    the total packet size does not exceed the path MTU.

  I'd recommend adding: "If the path MTU is unknown, a maximum packet
  size of 512 octets SHOULD be used."


Section 11., paragraph 4:

>    IPFIX Messages can be secured using IPsec.  Alternatively if IPFIX
>    runs on top of SCTP or TCP, TLS [TLS] can be used.

  For UDP, DTLS could be used.


Section 11.4, paragraph 3:

>    If IP address spoofing can not be prevented, some level of
>    protection against an insertion attack is required.  With a modern
>    implementation of TCP with good ISN randomization [RFC1948] or SCTP
>    insertion such attacks are difficult without the ability to snoop
>    the packet Flow [RFC2960].  UDP is vulnerable to insertion attacks,
>    and SHOULD be protected by the use of the address restriction
>    mechanism described above.

  DTLS for UDP?


Section 12., paragraph 2:

>    New assignments in either IPFIX Version Number or IPFIX Set ID
>    assignments require an Standards Action [RFC2434], i.e. they are to
>    be made via Standards Track RFCs approved by the IESG.

  Nit: s/an Standards Action/a Standards Action/