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

An updated Note to RFC Editor was added to the write-up to solve the concerns raised in the DISCUSS by Russ Housley.

Note to RFC Editor

Please make the following changes:

1. Add at the end of the currect Section 11.3 the following paragraph:

NEW:

Internationalized domain names (IDN) in either the subjectAltName
extension of type dNSName or the most specific Common Name field of the
Subject field of the X.509 certificate MUST be encoded using Punycode
[RFC3492] as described in Section 4, "Conversion Operations", of
[RFC3490].

2. Add to Section 14.1 the following two normative references:

NEW:

  [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
                "Internationalizing Domain Names in Applications (IDNA)",
                RFC 3490, March 2003.

  [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
                Unicode for use with Internationalized Domain Names in
                Applications (IDNA)", RFC 3492, March 2003.

[Ballot discuss]
In Section 11.3, the document says:
  >
  > The fully-qualified domain name used to identify an IPFIX Collecting
  > Process or Exporting Process may be stored either in a subjectAltName
  > extension of type dNSName, or in the most specific Common Name field
  > of the Subject field of the X.509 certificate.  If both are present,
  > the subjectAltName extension is given preference.
  >
  When the common name is used, how is the fully-qualified domain name
  encoded in the directory string?  This is especially important to
  specify in order to support IDNs.  I suspect that punycode will be
  needed.

The expected resolution is a new paragraph 4 of section 11.3:

  Internationalized domain names (IDN) in either the subjectAltName
  extension of type dNSName or the most specific Common Name field of
  the Subject field of the X.509 certificate MUST be encoded using
  Punycode [RFC3492] as described in Section 4, "Conversion
  Operations", of [RFC3490].

with the following new normative references:

  [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

  [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
              Unicode for use with Internationalized Domain Names in

[Ballot comment]
In at least two places, the document says:
  >
  > The Exporting Process uses the Observation Domain ID to uniquely
  > identify to the Collecting Process the Observation Domain that
  > metered the Flows.  It is RECOMMENDED that this identifier is also
  > unique per IPFIX Device.
  >
  The document offers no advice about the assignment of these
  identifiers to meet this recommendation.  Is is provided in some
  other IPFIX document?  If so, please reference it.

  In Section 11.1: s/man in the middle/man-in-the-middle/

[Ballot discuss]
In Section 11.3, the document says:
  >
  > The fully-qualified domain name used to identify an IPFIX Collecting
  > Process or Exporting Process may be stored either in a subjectAltName
  > extension of type dNSName, or in the most specific Common Name field
  > of the Subject field of the X.509 certificate.  If both are present,
  > the subjectAltName extension is given preference.
  >
  When the common name is used, how is the fully-qualified domain name
  encoded in the directory string?  This is especially important to
  specify in order to support IDNs.  I suspect that punycode will be
  needed.

[Note]: 'A previous version draft-ietf-ipfix-protocol-24.txt of this draft was
already approved by the IESG. The IPFIX WG decided to make changes to that
version of the document with the principal goal of removing the SCTP
stream 0 restriction. Reviews should focus on the changes since
draft-ietf-ipfix-protocol-24.txt which are mentioned in an editorial note
currently placed after the Table of Contents.
' added by Dan Romascanu

[Note]: 'A previous version draft-ietf-ipfix-protocol-24.txt of this draft was
already approved by the IESG. The IPFIX WG decided to make changes to that
version of the document with the principal goal of removing the SCTP
stream 0 restriction. Reviews should focus on the changes since
draft-ietf-ipfix-protocol-26.txt which are mentioned in an editorial note
currently placed after the Table of Contents.
' added by Dan Romascanu

IANA Last Call comments:

For draft-ietf-ipfix-protocol-24.txt, IANA created the following new registries and populated them with their initial assignments:

- IPFIX Version Numbers
- IPFIX Set IDs

Please see: http://www.iana.org/assignments/ipfix-parameters

We understand the above to be the only IANA Actions for this document.

State Change Notice email list have been change to n.brownlee@auckland.ac.nz, fluffy@cisco.com, n.brownlee@auckland.ac.nz, plonka@doit.wisc.edu, bclaise@cisco.com from n.brownlee@auckland.ac.nz, n.brownlee@auckland.ac.nz, plonka@doit.wisc.edu, bclaise@cisco.com

[Ballot discuss]
This rev did a great job of addressing everyone of the comments I had put in. Thank you. I think it the new text has a few problems which are easily resolvable.

In section 11.2 paragraph two it says that one MUST implement SCTP and SCTP-PR over DTLS as described in 4337. However, 4347 does not describe this and as written it is not implementable. I think there is a trivial fix for this - you need to say as described in the tuxen draft and put in a normative reference to that draft.

I think the text in section 11.3 is still leaves too much undefined - for example - do you use CommonName of SubjectAltName. However, if Russ and Sam are ok with this as is, then it is fine by me. I think it would be good to have the security ADs just read this.

Last point has to do with the ports. I like how you have defined the multiplexing using the ports. I note that the SCTP and TCP stuff in section 10 does not mention ports but should and that the where the ports are mentioned for UDP it does not mention the different port when using DTLS which adds to confusion. I note that 3 ports have been registered with IANA for this protocol - I think we should ask IANA to free the unused unless it is clear why we need to keep in reserved. I really don't know the answer to this but do we need to do anything in the IANA section of this document to move the port registration to be associated with this document instead of the private registration that someone when and did.

Any ETA on a new rev of this - we talked about it at last IETF and I thought we had come up with good path to resolve all these?

[Ballot discuss]
> SCTP [RFC2960] and PR-SCTP [RFC3758] MUST be implemented by all
> compliant implementations.  UDP [UDP] MAY also be implemented by
> compliant implementations.  TCP [TCP] MAY also be implemented by
> compliant implementations. 
>
> ...
>
> When IPFIX uses UDP as the transport protocol, Template Sets and
> Option Template Sets MUST be re-sent at regular intervals.  The
> frequency of (Options) Template transmission MUST be configurable. 
> New Template Records SHOULD be transmitted as soon as they are
> created, and SHOULD be transmitted before any associated Data Record
> is transmitted. 
>             
> In the event of configuration changes, the Exporting Process SHOULD
> send multiple copies of the new template definitions, in different
> IPFIX Messages, at an accelerated rate.  In such a case, it MAY
> transmit the changed Template Record(s) and Options Template
> Record(s), without any data, in advance to help ensure that the
> Collector will have the correct template information before
> receiving the first data.
> ...
> The Collecting Process could deduce the loss and reordering of IPFIX
> Data Records by looking at the discontinuities in the IPFIX Message
> sequence number. In the case of UDP, the IPFIX Message sequence
> number contains the total number of IPFIX Data Records received for
> the UDP association, prior to the receipt of this IPFIX Message,
> modulo 2^32. IPFIX sequence number discontinuities SHOULD be logged.
> 
> Templates sent from the Exporting Process to the Collecting 
> Process using UDP as a transport MUST be resent at regular 
> intervals in case previous copies were lost.  Implementations 
> MAY send templates using a reliable transport protocol, and 
> send IPFIX Data Records using UDP as the transport protocol.
> ...
> Template Withdraw Messages SHOULD NOT be sent over UDP.   
> ...       
> Because UDP is not a connection oriented protocol, the Exporting
> Process is unable to determine from the transport protocol that the
> Collecting Process is no longer able to receive the IFPIX Messages. 
> Therefore, it can not invoke a failover mechanism.  However, the
> Exporting Process MAY duplicate the IPFIX Message to several
> Collecting Processes.
>
> ...
>
> 8.    Template Management
>
> This section describes Template management when using SCTP and PR-
> SCTP as the transport protocol. Any necessary changes to Template
> management specifically related to TCP or UDP transport protocols
> are specified in section 10.
 
The large set of transport options make me uneasy about real-world
interoperability. In particular, I'm worried about the lack of
guidelines and default values for re-sending, duplicate sending,
whether sequence number tracking is required, and how and how
often templates are sent. Please add such guidelines and
default values.

COMMENT part follows:

Given that withdrawals need to use a reliable
transport and SCTP is a MUST, one possible simplifying
assumption would be to say that templates are always
sent over a reliable transport.

I'm also worried about implementation complexity. Was there really a
requirement for all of these options? Is it likely that implementations
follow the MUST requirement, or is the long list an indication
that different groups intend to use different transports, making
interoperability less likely?

[Ballot comment]
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.

[Ballot discuss]
I considered deferring to give me a chance to talk to the authors - I suspect that many of these things may just be my misunderstanding and can be easily cleared up. I decided to just stick them in and we can start a discussion to clear them up.

I'm concerned about what is the recommended mode for using this. It seemed like it was secure with TLS and also for DOS reasons use SCTP-PR. But iI don't think you can do both of these at the same time. What is the recommended way to sue this protocol?

I do not understand how the requirements in section 10.2 of the IPFIX-ARCH are achieved when using IPSEC.

I do not understand the advantages of SCTP over having an TCP connection for each set of messages that would go on a single stream in SCTP.

There is no advice on how to use SCTP streams (other than stream 0).

DTLS seems like an obvious candidate to meet many of your requirements. Why not include it?

Section 10.3.1 leaves me wondering if UDP is deprecated or not and when would it be ok to use it. This really needs clarification. I have no idea what a link is that runs UPD but where it is not possible to have congestion. Imagine I told this protocol to log all the packets that this protocol sent including a full copy of them.

How does a collector listen for both TCP and TLS packets on the same port? I can imagine this is possible to demux but I think it is worth explaining.

I think more advice is needed on checking the names in TLS certificates and checking the certificates are valid.

[Ballot discuss]
I considered deferring to give me a chance to talk to the authors - I suspect that many of these things may just be my misunderstanding and can be easily cleared up. I decided to just stick them in and we can start a discussion to clear them up.

I'm concerned about what is the recommended mode for using this. It seemed like it was secure with TLS and also for DOS reasons use SCTP-PR. But iI don't think you can do both of these at the same time. What is the recommended way to sue this protocol?

I do not understand how the requirements in section 10.2 of the IPFIX-ARCH are achieved when using IPSEC.

I do not understand the advantages of SCTP over having an TCP connection for each set of messages that would go on a single stream in SCTP.

There is no advice on how to use SCTP streams (other than stream 0).

DTLS seems like an obvious candidate to meet many of your requirements. Why not include it?

Section 10.3.1 leaves me wondering if UDP is deprecated or not and when would it be ok to use it. This really needs clarification. I have no idea what a link is that runs UPD but where it is not possible to have congestion. Imagine I told this protocol to log all the packets that this protocol sent including a full copy of them.

How does a collector listen for both TCP and TLS packets on the same port? I can imagine this is possible to demux but I think it is worth explaining.

I think more advice is needed on checking the names in TLS certificates and checking the certificates are valid.

[Ballot comment]
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?

[Ballot discuss]
Reference issues:

[IPFIX-ARCH] is expired; I guess it got renamed from -arch to -architecture?

[RFC1948] is informational, so is a downref.  I suspect it's not actually normative, from the context, but if it is this needs to be handled with the 3967 rules.

[Ballot discuss]
> SCTP [RFC2960] and PR-SCTP [RFC3758] MUST be implemented by all
> compliant implementations.  UDP [UDP] MAY also be implemented by
> compliant implementations.  TCP [TCP] MAY also be implemented by
> compliant implementations. 
>
> ...
>
> When IPFIX uses UDP as the transport protocol, Template Sets and
> Option Template Sets MUST be re-sent at regular intervals.  The
> frequency of (Options) Template transmission MUST be configurable. 
> New Template Records SHOULD be transmitted as soon as they are
> created, and SHOULD be transmitted before any associated Data Record
> is transmitted. 
>             
> In the event of configuration changes, the Exporting Process SHOULD
> send multiple copies of the new template definitions, in different
> IPFIX Messages, at an accelerated rate.  In such a case, it MAY
> transmit the changed Template Record(s) and Options Template
> Record(s), without any data, in advance to help ensure that the
> Collector will have the correct template information before
> receiving the first data.
> ...
> The Collecting Process could deduce the loss and reordering of IPFIX
> Data Records by looking at the discontinuities in the IPFIX Message
> sequence number. In the case of UDP, the IPFIX Message sequence
> number contains the total number of IPFIX Data Records received for
> the UDP association, prior to the receipt of this IPFIX Message,
> modulo 2^32. IPFIX sequence number discontinuities SHOULD be logged.
> 
> Templates sent from the Exporting Process to the Collecting 
> Process using UDP as a transport MUST be resent at regular 
> intervals in case previous copies were lost.  Implementations 
> MAY send templates using a reliable transport protocol, and 
> send IPFIX Data Records using UDP as the transport protocol.
> ...
> Template Withdraw Messages SHOULD NOT be sent over UDP.   
> ...       
> Because UDP is not a connection oriented protocol, the Exporting
> Process is unable to determine from the transport protocol that the
> Collecting Process is no longer able to receive the IFPIX Messages. 
> Therefore, it can not invoke a failover mechanism.  However, the
> Exporting Process MAY duplicate the IPFIX Message to several
> Collecting Processes.
>
> ...
>
> 8.    Template Management
>
> This section describes Template management when using SCTP and PR-
> SCTP as the transport protocol. Any necessary changes to Template
> management specifically related to TCP or UDP transport protocols
> are specified in section 10.
 
The large set of transport options make me uneasy about real-world
interoperability In particular, I'm worried about the lack of guidelines and
default values for re-sending, duplicate sending, whether
sequence number tracking is required, and how and how
often templates are sent.

Given that withdrawals need to use a reliable
transport and SCTP is a MUST, one possible simplifying
assumption would be to say that templates are always
sent over a reliable transport.

COMMENT part follows:

I'm also worried about implementation complexity. Was there really a
requirement for all of these options? Is it likely that implementations
follow the MUST requirement, or is the long list an indication
that different groups intend to use different transports, making
interoperability less likely?

[Ballot discuss]
> SCTP [RFC2960] and PR-SCTP [RFC3758] MUST be implemented by all
> compliant implementations.  UDP [UDP] MAY also be implemented by
> compliant implementations.  TCP [TCP] MAY also be implemented by
> compliant implementations. 
>
> ...
>
> When IPFIX uses UDP as the transport protocol, Template Sets and
> Option Template Sets MUST be re-sent at regular intervals.  The
> frequency of (Options) Template transmission MUST be configurable. 
> New Template Records SHOULD be transmitted as soon as they are
> created, and SHOULD be transmitted before any associated Data Record
> is transmitted. 
>             
> In the event of configuration changes, the Exporting Process SHOULD
> send multiple copies of the new template definitions, in different
> IPFIX Messages, at an accelerated rate.  In such a case, it MAY
> transmit the changed Template Record(s) and Options Template
> Record(s), without any data, in advance to help ensure that the
> Collector will have the correct template information before
> receiving the first data.
> ...
> The Collecting Process could deduce the loss and reordering of IPFIX
> Data Records by looking at the discontinuities in the IPFIX Message
> sequence number. In the case of UDP, the IPFIX Message sequence
> number contains the total number of IPFIX Data Records received for
> the UDP association, prior to the receipt of this IPFIX Message,
> modulo 2^32. IPFIX sequence number discontinuities SHOULD be logged.
> 
> Templates sent from the Exporting Process to the Collecting 
> Process using UDP as a transport MUST be resent at regular 
> intervals in case previous copies were lost.  Implementations 
> MAY send templates using a reliable transport protocol, and 
> send IPFIX Data Records using UDP as the transport protocol.
> ...
> Template Withdraw Messages SHOULD NOT be sent over UDP.   
> ...       
> Because UDP is not a connection oriented protocol, the Exporting
> Process is unable to determine from the transport protocol that the
> Collecting Process is no longer able to receive the IFPIX Messages. 
> Therefore, it can not invoke a failover mechanism.  However, the
> Exporting Process MAY duplicate the IPFIX Message to several
> Collecting Processes.
>
> ...
>
> 8.    Template Management
>
> This section describes Template management when using SCTP and PR-
> SCTP as the transport protocol. Any necessary changes to Template
> management specifically related to TCP or UDP transport protocols
> are specified in section 10.
 
The large set of transport options make me uneasy about real-world
interoperability and implementation complexity. Was there really a
requirement for all of these options? Is it likely that implementations
follow the MUST requirement, or is the long list an indication
that different groups intend to use different transports, making
interoperability less likely? (This part of my note is only a
COMMENT.)

In particular, I'm worried about the lack of guidelines and
default values for re-sending, duplicate sending, whether
sequence number tracking is required, and how and how
often templates are sent.

Given that withdrawals need to use a reliable
transport and SCTP is a MUST, one possible simplifying
assumption would be to say that templates are always
sent over a reliable transport.

[Ballot discuss]
Based on a security review from Radia Perlman as well as my own comments.

BCP 61 requires a mandatory to implement strong security solution for
this protocol.  However Section 11.1.6 makes it clear that IPsec is
not mandated and 11.2 does not mandate TLS.  Section 11.4 does not
provide adequate protection for the Internet threat model.  DTLS and
TLS are certainly easier to deploy, although writing the binding for
SCTP (the mandatory transport) may be tricky.  If you decide to make
IPsec mandatory, then to make it reasonable to deploy, you will
probably need to mandate that given some small set of configuration
information (peer identities, local identities), an IPFIX
implementation must be able to set up default SPD rules and other
IPsec configuration.  It's not sufficient to create a deployable
solution to simply mandate IPsec and to tell administrators how to set
up a complex set of IPsec configurations.



BCP 107 provides a set of guidelines for automated key management.  I
believe under that analysis, automated key management is a requirement
for this protocol.

Radia indicated she could not determine how in the configuration where
TCP and UDP are used together, the templates sent over TCP were linked
to the data sent over UDP; with a quick look I could not determine
this either.

One significant problem with both TLS and IPsec in this document is
that you don't describe how IPFIX entities are named.  What identities
are expected in a certificate?

IPsec should use ESP (possibly with null encryption) rather than AH;
ESP and AH together are definitely not the recommended way to get
confidentiality and integrity.  What do the rules in 11.1.1 and 11.1.4
mean in terms of SPD entries?  11.1.1 is possibly clear enough
although an explicit example would be helpful.  11.1.4 needs to be
more clear.  Presumably this means a discard rule for any traffic on
port 4739 after protect rules for designated peers.

Unfortunately RFC 2401 does not seem to support SCTP port selectors,
so this may need to depend on RFC 4301 and IKEV2.  That may limit
IPsec's value as a mandatory to implement security solution and
encourage the WG to choose something else.


Section 11.2 is not sufficient for interoperable implementations.  How
is TLS requested and signaled?

[Ballot discuss]
Based on a security review from Radia Perlman as well as my own comments.

BCP 61 requires a mandatory to implement strong security solution for
this protocol.  However Section 11.1.6 makes it clear that IPsec is
not mandated and 11.2 does not mandate TLS.  Section 11.4 does not
provide adequate protection for the Internet threat model.  DTLS and
TLS are certainly easier to deploy, although writing the binding for
SCTP (the mandatory transport) may be tricky.  If you decide to make
IPsec mandatory, then to make it reasonable to deploy, you will
probably need to manadate that given some small set of configuration
information (peer identities, local identities), an IPFIX
implementation must be able to set up default SPD rules and other
IPsec configuration.  It's not sufficient to create a deployable
solution to simply mandate IPsec and to tell administrators how to set
up a complex set of IPsec configurations.



BCP 107 provides a set of guidelines for automated key management.  I
believe under that analysis, automated key management is a requirement
for this protocol.

Radia indicated she could not determine how in the configuration where
TCP and UDP are used together, the templates sent over TCP were linked
to the data sent over UDP; with a quick look I could not determine
this either.

One significant problem with both TLS and IPsec in this document is
that you don't describe how IPFIX entities are named.  What identities
are expected in a certificate?

IPsec should use ESP (possibly with null encryption) rather than AH;
ESP and AH together are definitely not the recommended way to get
confidentiality and integrity.  What do the rules in 11.1.1 and 11.1.4
mean in terms of SPD entries?  11.1.1 is possibly clear enough
although an explicit example would be helpful.  11.1.4 needs to be
more clear.  Presumably this means a discard rule for any traffic on
port 4739 after protect rules for designated peers.

Unfortunately RFC 2401 does not seem to support SCTP port selectors,
so this may need to depend on RFC 4301 and IKEV2.  That may limit
IPsec's value as a mandatory to implement security solution and
encourage the WG to choose something else.


Section 11.2 is not sufficient for interoperable implementations.  How
is TLS requested and signaled?

[Ballot comment]
"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?

[Ballot discuss]
Page 13:
  Sequence Number
          Incremental sequence counter modulo 2^32 of all IPFIX Data
          Records sent on this stream from the current Observation
          Domain by the Exporting Process.  This value SHOULD be used
          by the Collecting Process to identify whether any IPFIX Data
          Records have been missed.  Template and Options Template
          Records do not increase the Sequence Number.

The term "stream" is not defined. This results in that there is not clear that one can implement this in an interoperable way.

[Ballot comment]
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/

[Ballot comment]
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 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/

IANA Last Call Comments:

In the first paragraph of the IANA Considerations section, "them" should be more explicit.
What does the word "them" refer to?

We understand this document to create 2 new registries:
IPFIX Version numbers
IPFIX Set IDs

Should the new registries be placed in a new separate location? For example a new location
named ipfix-parameters? Or, should it be nested within an existing registry?

The values that are described in section 12 (0, 1, 2 and 3) appear to be for Set IDs. Are
there any initial values for version numbers?

For the data set values, are these NOT assigned by IANA?

Section 12 also describes how "changes" can be made to the registry. Does "changes"
include both new registrations and modifications to existing registrations?

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

We understand Standards Action RFCs are needed to make changes to these registries.

Please clarify our questions above.

AD review posted to WG list:

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Wijnen, Bert (Bert)
Sent: Wednesday, March 15, 2006 01:22
To: 'Ipfix Wg' (E-mail) (E-mail)
Cc: David Kessens (E-mail); Dan Romascanu (E-mail)
Subject: [ipfix] AD review for: draft-ietf-ipfix-protocol-19.txt


Sorry for the long delay.

WG chairs/editors, pls let me (us ADs) know if you want to respin a new
rev first before we do IETF Last Call.

- Sect 3.
  States that Template Sets MUST be sent periodically when UDP is used.
  What if TCP or or SCTP are used? Might want to state what expected
  behaviour is in those cases as well.

- sect 3.1 under SOurce ID
  I do not understand the last sentence. WHat does it mean?
  pls clarify in text.

- Page 16 under padding
  s/zero (0) octets/zero (0) valued octets/
  or "octets with a value of zero (o)" ??
  Last sentence under "padding" may need a period or semicolon in
  the middle of the sentence?

- Sect 5/6 speak about ...DeltaUSeconds, but I cannot find that term in
  INFO spec. It talks about ...DeltaMicroSeconds. Is that what you mean?

- sect 6.1.3
  I'd like to see a reference to the IEEE spec for floats.

- sect 6.1.5
  I am not sure that by saying "it is expected that strings will be coded
  in UTF-8 format" will guanrantee interoiperability?
  Maybe better use MUST (RFC2119) language.
  Last sentence of 6.1.5 talks about "NUL" characters. That again seems
  to be ASCII language. Maybe better state "zero valued octets" .

- sect 6.1.6
  YOu might want to add a sentence how long this can serve us.
  I believ it is something like 146 years,

- sect 6.2 speaks about signed64/unsigned64 and also for 32 and 16.
  Where are those types defined??

- one but last para on page 33
  "sufficient time" should be defined/explained somewhat don't
  you think so?

- Page 35.
  Should the "All Data Templates" be changed into "All Templates" ??

- I wonder if the one but last para of section 9 is a nice opening
  for DoS attacks?

- Sect 10.1 and 10.2 seem inconsistent in the use of SCTP-PR and
  PR-SCTP

- sect 10.2.6
  Where/how is the treshold specified?
  Same for sect 10.4.1.1

- sect 10.3.7
  It is unclear to me how/where the template lifetimes are specified,
  defined or configured.

- sect 11.4 last para
  I guess that just depends of who/where the attacker is, no?
  WHat if it is an internal ISP employee?

- sect 12.1
  I do not think the IPfix version number is an IANA controlled thing.
  I also think you want that to be changebale only by an IETF standards
  action (as opposed to just IETF consensus). Afetr all you want this
  protocol to be stds track.

- sect 12.2 seems to be IPFIX-INFO material and not protocol material??

- sect 12
  You have already gotten ports for UDP, SCTP and TCP.
  Sect 10.2.4.1 however does not list the port number.
  You may want to list the port there, and maybe in the IANA considerations
  you want to say/state that Nevil has already got port numbers for TCP,
  UDP and SCTP assigned via IANA.

- sect 12.
  Sect 11.1.1 talsk about IANA assigning Selectors. I guess this needs
  to be documented under IANA Considerations too.

- Sect 12.1
  The "IPFIX Set ID" starts (I think) a new registry. So you MUST
  describe under IANA considerations how to set it up and what the
  rules are for new assignements. You have that text (more or less) in
  sect 3.3.2, but you must spell it out here for IANA as well.

  Then you have a set of Set IDs that get assigned by this document
  and you should list them clearly for IANA so they can do the initial
  population of the registry.

- It seems to me that sect 13 is more an APPENDIX and so non-normative?
  Might be good to then list it as appendix and state that it is
  non-normative.

- Refrences.
  - is 1889 really normative?


admin/nits/spelling

- references/citation issues:

  !! Contains embedded space:
  P051 L048:    by IANA, on a First Come First Served basis [RFC 2434], subject to

  !! Contains embedded space:
  P052 L005:    Expert Review [RFC 2434], i.e. review by one of a group of experts

  !! Missing Reference for citation: [RFC768]
  P041 L036:    [RFC768]

  !! Missing citation for Informative reference:
  P060 L046:    [RFC3955] Leinen, S., "Evaluation of Candidate Protocols for IP Flow

- add citation to RFC2119 first time you mention 2119.

- sect 3.1 remove one of the two words "format"
  You migth also want to add a sentence to explain why the version
  field is 0x000a for this version.

- sect 3.1 under SOurce ID
  remove one of the two "the combination"

- sect 6.2
  s/smaller type/smaller size/ ??

- sect 7
  s/MUST/MUST be/

- page 33
  s/Disused/Unused/ ??

- the last par of the "Interllectual Property Statement" on page 63
  is normally not included in the RFC. So I would remove it.


Bert