Subject: [ipfix] changes in IPFIX requirements from -10 to -11

From: Juergen Quittek <[email-masked]>
Date: Wed, 29 Oct 2003 11:02:37 +0100

Dear all,

Below please find the list of changes from version -10 to version -11.
Not listed is a set of 20 minor changes, most of them based on comments
from Randy Presuhn, including
   - having two spaces after each period at the end of a sentence
   - fixing references
   - correcting grammar (commas, typos, word oder, ...)
   - removing "confidentiality" in overview sentences

Cheers,

    Juergen

--On 28.10.2003 15:41 Uhr -0500 [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IP Flow Information Export Working Group of the IETF.
>
> 	Title		: Requirements for IP Flow Information Export
> 	Author(s)	: J. Quittek
> 	Filename	: draft-ietf-ipfix-reqs-11.txt
> 	Pages		: 31
> 	Date		: 2003-10-28
> 	
> This memo defines requirements for the export of measured IP flow
> information out of routers, traffic measurement probes and
> middleboxes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-11.txt
>

=========================
IPFIX Requirements Issues
=========================

========================================================================
15. Confidentiality from SHOULD to MUST (issue 12 revisited)
========================================================================
Problem Description:
------------------------------------------------------------------------
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.

raised by Allison Mankin
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace
     "Confidentiality of flow specific data transferred from an exporting
      process to a collecting process SHOULD be ensured."
   by
     "Confidentiality of flow specific data transferred from an exporting
      process to a collecting process MUST be ensured."

   change confidentality from SHOULD to MUST in appendix
========================================================================
Status: solution committed
========================================================================

========================================================================
16. Anonymization from MAY to MUST (issue 13 revisited)
========================================================================
Problem Description:
------------------------------------------------------------------------
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.

raised by Allison Mankin
========================================================================
Suggested solution:
------------------------------------------------------------------------
After a long discussion, it was agreed to completely remove the issue of
anonymization from the requirements.  The main reason is that there are
neither standardized anonymisation methods available, nor is there a
solid knowledge base about the effectiveness of existing anonymization
methods.  Here is work to be done by the IETf for recommending which
anonymization should be applied in which case (and having which effect).
Since the goal of the IPFIX WG is targeted rather at standardizing
existing technology rather than developing new technologies (confirmed
several times by our AD rendy Bush), the WG identified this issue to be
out of scope.

In order to still document the need of anonymization, the security
considerations section was extended.

   remove Section
     "6.7.  Anonymization

         The exporting process MAY be capable of anonymizing source and
         destination IP addresses in flow data before exporting them. It MAY
         support anonymization of port numbers and other fields. Please note
         that anonymization is not originally an application requirement, but
         derived from general requirements for treatment of measured traffic
         data within a network.

         When anonymized flow data is exported, this MUST be clearly indicated
         to all receiving collecting processes, such that they can distinguish
         anonymized data from non-anonymized data."

   remove from Section 7.2 (configuration requirements)
        "5. flow anonymization
         This requirement only applies if the exporting process supports
         flow anonymization."

   remove confidentiality from appendix

   append to Section 10.1 (security considerations)
     "Also the privacy of users acting as sender or receiver of the
      measured traffic needs to be protected when they use the Internet.
      In many contries the right to store user-specific data (including the
      user's traffic profiles) is restricted by law or by regulations.

      In addition to encryption, this kind of privacy can also be protected
      by anonymizing flow records.  For many traffic flow measurements,
      anonymized data is as useful as precise data.  Therefore, it is
      desirable to support anonymization in IPFIX implementations.  It is
      beyond the scope of the IPFIX working group to develop and
      standardize anonymization methods.  However, the requirements for
      extensibility of the IPFIX protocol are sufficient to support
      anonymized flow records when appropriate methods are standardized."
========================================================================
Status: solution committed
========================================================================

========================================================================
17. For distinguishing flows, consider also SCTP
========================================================================
Problem Description:
------------------------------------------------------------------------
Section 4.3 requests the meter to be able to distinguish traffic by
TCP and UDP port numbers.  Also SCTP should be mentioned here.

raised by Steve Bellovin
========================================================================
Suggested solution:
------------------------------------------------------------------------
   Section 4.3 (Steve Bellovin's request to consider SCTP)

  replaced
  "4.3.  Transport Header Fields

      The metering process MUST be able to separate flows by the port
      numbers of the transport header in case of TCP or UDP being used as
      transport protocol. Both, source and destination port number MUST be
      supported for distinguishing flows, individually as well as in
      combination."

  by
  "4.3.  Transport Header Fields

      The metering process MUST be able to separate flows by the port
      numbers of the transport header in case of TCP or UDP being used as
      transport protocol.  The metering process SHOULD be able to separate
      flows by the port numbers of the transport header in case of SCTP
      [RFC2960].

      For separation, both, source and destination port number MUST be
      supported for distinguishing flows, individually as well as in
      combination."

  add reference
  "[RFC2960]   Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
               Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
               L. and V. Paxson, "Stream Control Transmission Protocol",
               RFC 2960, October 2000."
========================================================================
Status: solution committed
========================================================================

========================================================================
18. Dubious header compression in section 4.6
========================================================================
Problem Description:
------------------------------------------------------------------------
Steve Bellovin: 4.6 strikes me as dubious for compression
========================================================================
Suggested solution:
------------------------------------------------------------------------
  replace
  "4.6.  Header Compression and Encryption

      If header compression or encryption is used, the metering process
      might not be able to access all header fields. A metering process
      MUST meet the requirements stated in this section 4 only for packets
      that have the relevant header fields not compressed and not
      encrypted."

  by
  "4.6.  Encryption

      If encryption is used, the metering process might not be able to
      access all header fields.  A metering process MUST meet the
      requirements stated in this section 4 only for packets that have the
      relevant header fields not encrypted."
========================================================================
Status: solution committed
========================================================================

--
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/