Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-reqs-10.txt

From: Dave Plonka <[email-masked]>
Date: Thu, 12 Jun 2003 11:03:42 -0500

IPFIX folks,

Below please find the announcement regarding the availability of the
updated requirements draft.

The following link to it now appears on the IPFIX web site index:

   http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-10.txt

Its also mirrored here:

   http://ipfix.doit.wisc.edu/req/draft-ietf-ipfix-reqs-10.txt

Dave

----- Forwarded message from [email-masked] -----

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ipfix-reqs-10.txt
Date: Thu, 12 Jun 2003 07:19:15 -0400
Sender: [email-masked]

--NextPart

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 et al.
	Filename	: draft-ietf-ipfix-reqs-10.txt
	Pages		: 31
	Date		: 2003-6-11
	
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-10.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipfix-reqs-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-reqs-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-reqs-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-reqs-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

----- End forwarded message -----

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

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

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 13 Jun 2003 16:15:13 +0200

Dear all,

below please find the detailed list of all changes applied to the
Internet-Draft compared to version -09.

    Juergen

> 	Filename	: draft-ietf-ipfix-reqs-10.txt

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

========================================================================
1. timestamp resolution reference
========================================================================
Problem Description:
------------------------------------------------------------------------
   5.4.  Timestamps

     The metering process MUST be able to generate timestamps for the
     first and the last observation of a packet of a flow at the
     observation point. The timestamp resolution MUST be at least the one
     of the sysUpTime [RFC1213], which is one centisecond.

I think I'd rather see a reference to RFC3418 instead of RFC1213.
We can do so by RFC-Editor note. May want to check with authors too.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace ref to RFC1213 by ref to RFC3418
========================================================================
Status: solution committed
========================================================================

========================================================================
2. reporting TOS/traffic class octet or reporting DSCP
========================================================================
Problem Description:
------------------------------------------------------------------------
On page 14 I see:

      9. type of service octet (in case of IPv4), traffic class
         octet (in case of IPv6)

Is that not better state as

      9. DSCP, which is set in the type of service octet (in case of IPv4),
         or in the traffic class octet (in case of IPv6)
========================================================================
Suggested solution:
------------------------------------------------------------------------
   According to RFC 2474, the DSCP covers only 6 bit of the type of
   service octet, and in some cases you want to see the entire byte.
   This is be pointed out by a comment added to item 9.:
   "According to RFC 2474 these octets include the DiffServ Code Point
   that has a length of 6 bit."
========================================================================
Status: solution committed
========================================================================

========================================================================
3. location of reference to RFC 2119
========================================================================
Problem Description:
------------------------------------------------------------------------
   I would prefer to see the paragraph referencing RFC 2119 in section 2.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   Move reference to RFC 2119 to section 2
========================================================================
Status: solution committed
========================================================================

========================================================================
4. bad wording in section 6.3.3, last paragraph
========================================================================
Problem Description:
------------------------------------------------------------------------
   Last paragraph in section 6.3.3 needs to be reworded.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace
     "The security threats from which these 3 requirements are deducted
      are explained in the "Security Considerations" (Section 10)."
   by
     "The security requirements have been derived from an analysis of
      potential security threads. The analysis is summarized in
      Section 10."
========================================================================
Status: solution committed
========================================================================

========================================================================
5. describe potential problem of faked DoS attack
========================================================================
Problem Description:
------------------------------------------------------------------------
   In section 10.2, an important point is left unsaid.  If the injection of
IPFIX traffic fool the network provided into thinking that a DOS attack is
underway, the countermeasures employed by the network provider may actually
deny service to real customers.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace the entire section 10.2 Forgery of Flow Records:
     "If flow records are used in accounting and security applications,
      there are potentially strong incentives to forge exported IPFIX flow
      records (for example to save money or prevent the detection of an
      attack). This can be done either by altering flow records on the path
      or by injecting forged flow records that pretend to be originated by
      the original exporting process. In order to make an IPFIX protocol
      resistant against such attacks, authentication and integrity must be
      provided, as specified in section 6.3.3.

      Special caution is required if security applications rely on flow
      measurements. With forged flow records it is possible to trick on
      security applications. It is for instance possible to pretend that a
      DoS attack happens without even launching a real attack."
   by
     "If flow records are used in accounting and/or security applications,
      there are potentially strong incentives to forge exported IPFIX
      flow records (for example to save money or prevent the detection
      of an attack). This can be done either by altering flow records
      on the path or by injecting forged flow records that pretend to
      be originated by the original exporting process.

      Special caution is required if security applications rely on flow
      measurements. With forged flow records it is possible to trick on
      security applications. It is for instance possible to pretend that
      a DoS attack happens without even launching a real attack. If such
      an injection of IPFIX traffic flow records fools the security
      application, pretending that a DoS attack is underway, then the
      countermeasures employed by the security application may actually
      deny useful non-malicious services.

      In order to make an IPFIX protocol resistant against such attacks,
      authentication and integrity must be provided, as specified in
      section 6.3.3."
========================================================================
Status: solution committed
========================================================================

========================================================================
6. location of appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
   The appendix needs to be moved up in the document.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   move appendix above references, copyright, and authors' addresses
========================================================================
Status: solution committed
========================================================================

========================================================================
7. consistency of appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
   The appendix is outdated. Alignment with the text sections and
   coverage of all requirements need to be checked and fixed.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   --- 5.2 Sampling
   Insert note (h): "If sampling is supported, sampling configuration
   changes MUST be indicated to all collecting processes."

   --- 5.3 Overload behavior
   Insert note (i): "If overload behavior is supported and it induces
   changes in the metering process behavior, the overload behavior MUST
   be clearly defined."

   --- Requirement on packet fragmentation state at the meter is
   missing (section 5.8)
   Add "5.8 Packet Fragmentation state O O - - - O"

   --- 6.1 Dropped packet counter:  This requirement appears as a MUST
   in the appendix, but it is a MAY in current section 6.1
   Replace with: "6.1 Dropped packet counter (h,i) O O O O O O"

   --- 6.1 ToS byte and DSCP: they appear as separate requirements in
   the appendix. Besides, Traffic Class (IPv6) is not mentioned.
   Remove line "6.1 ToS Byte M S M O M M" and leave only
   "6.1 DSCP (a) M S M O M M"

   --- 6.1 BGP AS# is given as MUST in the appendix, but it is a
   MAY in current section 6.1
   Replace "6.1 BGP AS# - S M - - M" with the following line:
   "6.1 src/dst/next hop BGP AS # - O O - - O"

   --- For the Information Model, requirements on ICMP type,
   in/out interface and next hop IP address are missing:
   Add "6.1 ICMP type and code (l) S S - S S S"
   Add note: "(l) If protocol type is ICMP"

   Add "6.1 input/output interface (m) S S S S S S"
   Add note: "(m) This requirement does not apply if the observation
   point is located at a probe device"

   Add "6.1 next hop IP address  O O O O - O
   --- For the Data Model the following requirement is missing:
   "6.2 Independency of the transport protocol S S S S S S"

   --- "6.7 Anonymization O O O O O O"
   Add note: "(n) anonymization MUST be clearly indicated to all
   receiving collecting processes"

   --- Remote configuration requirements:
   Replace "7 Config Measurement & Data Export M M M M M M"
   by "7 Secure remote configuration (a) S S S S S S"

   --- Configuration requirements for metering process:
   Add "7.1 Config overload behavior (a) O O O O O O"

   --- Configuration reqs. for exporting process:
   Config Notifications and Config Anonymization should be changed
   to SHOULD (they are listed as MAY)

   Add the following missing reqs:
   "Config collecting processes S S S S S S"
   "Config reporting interval (a) S S S S S S"
========================================================================
Status: solution committed
========================================================================

========================================================================
8. More concrete definition of byte counter
========================================================================
Problem Description:
------------------------------------------------------------------------
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

      8. byte counter
         Which bytes of a packet are counted MUST be defined exactly.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace "Which bytes of a packet are counted MUST be defined
   exactly." by "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."
========================================================================
Status: solution committed
========================================================================

========================================================================
9. More concrete definition of multicast replication factor
========================================================================
Problem Description:
------------------------------------------------------------------------
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

     20. multicast replication factor
         the number of outgoing packets originating from a single
         incoming multicast packet. This is a dynamic property of
         multicast flows, that may change over time. For unicast flows
         it has the constant value 1. The computation of the factor MUST
         be clearly defined.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace last sentence by "The reported value MUST be the value of the
   factor at the time the flow record is exported."
========================================================================
Status: solution committed
========================================================================

========================================================================
10. More concrete definition of BGP-related attributes
========================================================================
Problem Description:
------------------------------------------------------------------------
Also, at the end of 6.1 it kind of says "Plus other stuff related to inter-AS
routing if you want".  It's already in the MAY section; can't they just
list some concrete items related to inter-AS routing as 27, 28, ...?
I don't think it's useful to say what amounts to "plus anything else that
you might feel like adding that you think is relevant", since that doesn't
encourage different people to make the same choices.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   add three more MAY attributes:
   - 27. source BGP Autonomous System number [RFC1771]
   - 28. destination BGP Autonomous System number
   - 29. next hop BGP Autonomous System number
========================================================================
Status: solution committed
========================================================================

========================================================================
11. Address the reliability issue of usage based accounting
========================================================================
Problem Description:
------------------------------------------------------------------------
The applications include usage-based accounting.  They should cite RFC 2975,
and indicate that the particular niche for usage-based accounting would not
be met if reliability was not very high.  Section 5.1 reliability requirements
do not meet the needs, nor do the timestamping of first and last packet of
a flow, because the flow may have been mischaracterized and that is first and
last of different flows.  The way to satisfy this issue is to caveat the
discussion of usage-based accounting with strong words on reliability that
counter the comments on lesser reliability and more probabilistic techniques
for other applications of ipfix.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   remove from section 3:
     "Please note, that the described applications can have a large number
      of differing implementations. Requirement details or the weighting of
      requirements could differ for specific implementations. Therefore we
      derive the requirements from the general functionality of the
      selected applications."
   append to section 3.:
     "Please note, that the described applications can have a large
      number of differing implementations. Requirement details or
      requirement significance (MANDATORY (MUST), RECOMMENDED (SHOULD),
      OPTIONAL (MAY)) could differ for specific implementations and/or
      for specific application scenarios. Therefore we derive the
      requirements from the general functionality of the selected
      applications. Some particular cases will even mandate more
      stringent requirements than the ones defined in this
      document. For example, usage-based accounting is certainly the
      application that will probably mandate the highest degree of
      reliability amonst the applications discussed below. The
      reliability reqirements defined in sections 5.1 and 6.3.2. are
      not sufficient to guarantee the level of reliability that is
      needed for many usage-based accounting systems. Particular
      reliability requirements for accounting systems are discussed
      in [RFC2975]."
   add reference to RFC 2975 to References section
========================================================================
Status: solution committed
========================================================================

========================================================================
12. Confidentiality from SHOULD to MUST
========================================================================
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.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   insert in section 1. Introduction after third sentence:
     "They serve as input to the standardization of an IPFIX protcol."

   append to section 1, Introduction:
     "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).

      Note that the protocol specification and related standard
      documents themselves also assign significance attributes to its
      features, such that a protocol implementation does not
      necessarily need to implement all features. However, the
      implementations significance atributes need to match those
      of the corresponding IPFIX requirements."
========================================================================
Status: solution committed
========================================================================

========================================================================
13. Anonymization from MAY to MUST
========================================================================
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.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   see solution of issue 12
========================================================================
Status: solution committed
========================================================================

========================================================================
14. Move paragraph on remote configuration up (out of section 7.2)
========================================================================
Problem Description:
------------------------------------------------------------------------
The paragraph is listed in the subsection on configuration of the
exporting process although it concerns configuration of the metering
process as well as configuration of the exporting process.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   move paragraph up before section 7.1.
========================================================================
Status: solution committed
========================================================================