Skip to main content

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

Yes

(Dan Romascanu)

No Objection

(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Sam Hartman)
(Ted Hardie)

Note: This ballot was opened for revision 26 and is now closed.

Lars Eggert
No Objection
Comment (2006-06-30) Unknown
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/
Cullen Jennings Former IESG member
(was No Objection, Discuss) Yes
Yes (2006-07-06) Unknown
Section 6.1 seems to duplicate type specifications that are also defined in the normative IPFIX-INFO reference. Normative definitions of things in two documents seems like a receipt for disaster. I would have preferred to see the the IPFIX-INFO document and this document as a ballot set. 

Interoperability for UDP would be improved in you recommended a default time for  retransmission of templates.

There are many places in this protocol where they are several options - I imagine arguments were made for all of them but the allowing all of them results in this being a surprisingly complex protocol when clearly the early desires were for something very simple. I'm thinking of things like the transport options, the security options, the date times options, the reduced size options, 

Using dates based on 2^32 seconds since 1970 always makes me shutter. 

Might be nice to have advice on accuracy of any of the times and perhaps suggest NTP. 

I am very curios about the interoperability events. Any TLS implementations? Which transport? Any SCTP-PR implementations? How did people use streams?
Dan Romascanu Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2006-10-25) Unknown
Note: the reference to draft-ietf-ipfix-architecture is technically a downref (see RFC 3967)
Brian Carpenter Former IESG member
No Objection
No Objection (2006-07-05) Unknown
"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?
David Kessens Former IESG member
No Objection
No Objection (2006-07-06) Unknown
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.
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2006-10-17) Unknown
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.
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
(was Discuss, No Objection) No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown