Subject: [ipfix] new IPFIX requirements draft

From: Juergen Quittek <[email-masked]>
Date: Wed, 28 Jan 2004 01:25:17 +0100

Dear all,

One of the modifications I did for the last version of the requirements
draft was done badly.  Russ Housley complained and I submitted a new version.

As usual, below please find the list of changes from version -14 to the new
version -15 of the IPFIX requirements draft.

Until it gets posted you can preview it at

<ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-15.txt>.

Cheers,

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

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

========================================================================
31. Bad phrasing in Section 4.3 (issue 26. revisited)
========================================================================
Problem Description:
------------------------------------------------------------------------
In the rephrased section 4.3 (previously numbered 4.2) is some bad
phrasing left.

raised by Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace

  "The metering process MUST, SHOULD, or MAY be able to separate flows
   by the following fields of the IP header as indicated."

by

  "The metering process MUST be able to separate flows by the following
   fields of the IP header:"
========================================================================
Status: solution committed
========================================================================

========================================================================
32. Badly phrasing in Section 4.2
========================================================================
Problem Description:
------------------------------------------------------------------------
The first sentence in section 4.2 is obsolete:
  "4.2.  Interfaces

      The metering process MUST be able to separate flows  by the following
      fields of the IP header: The metering process MUST be able to
      separate flows by the incoming interface or by the outgoing interface
      or by both of them."

raised by Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
remove first sentence.
========================================================================
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/

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Jan 2004 11:44:38 +0000

I believe that the security requirements (below) which were
enhanced by the IESG are an unreasonable burden on many
implementations.

The new requirements lack a measure of appropriateness which
needs to be incorporated in the definition.

For example there is no point in providing greater
confidentiality in the IPFIX protocol than exists at the
observation point itself.

There is no point in providing a level of integrity or
authenticity that exceeds the requirements of the collecting
application.

Setting the baseline for operation over the public Internet
leads to the inevitable conclusion that IPFIX MUST be run
over IPsec, but that is absurd in situations where the
network design precludes the possibility of data leakage
(for example where the IPFIX traffic is carried over a
private management network).

The net result of setting the bar at this level will be
either late and unnecessarily costly deployment of IPFIX,
or (more likely) the widespread deployment of non-compliant
IPFIX, thereby bringing the RFC into disrepute.

Section 6.3.3 should therefore be reworded to something
of the following form:

IPFIX data transferred from an exporting process to a
collecting process MUST NOT degrade the confidentiality of
the packet flows at the observation point.

The method of transferring IPFIX data from the exporting
process to the collecting process MUST provide the level
of data integrity required by the collecting application.

The authenticity of IPFIX data transferred from an exporting
process to a collecting process MUST be sufficient to meet
the application needs at the collector.

- Stewart

Original text for reference:

====================

6.3.3.  Security

    Confidentiality of IPFIX data transferred from an exporting process
    to a collecting process MUST be ensured.

    Integrity of IPFIX data transferred from an exporting process to a
    collecting process MUST be ensured.

    Authenticity of IPFIX data transferred from an exporting process to a
    collecting process MUST be ensured.

=====================

10.  Security Considerations

    An IPFIX protocol must be capable of transporting data over the
    public Internet.  Therefore it cannot be excluded that an attacker
    captures or modifies packets or inserts additional packets.