Subject: [ipfix] draft-leinen-ipfix-eval-contrib-03.txt posted

From: Simon Leinen <[email-masked]>
Date: Thu, 27 May 2004 00:56:16 +0200

I submitted a revision of the IPFIX Protocol Evaluation I-D.  Until it
shows up in the IETF repository, you can grab it at

http://www.switch.ch/misc/leinen/ietf/ipfix/draft-leinen-ipfix-eval-contrib-03.txt
http://www.switch.ch/misc/leinen/ietf/ipfix/draft-leinen-ipfix-eval-contrib-03.html

There's also an "htmlwdiff" from the previous version (-02):

http://www.switch.ch/misc/leinen/ietf/ipfix/draft-leinen-ipfix-eval-contrib-02-03-diff.html

In spite of its draft-leinen-... name, this is actually a WG item.
The revision was made to address some concerns that have been raised
during IESG review.

The most notable change I made is in the "Conclusions" section.  I
added two sections on things that must be added to NetFlow v9 to make
it viable as the IPFIX protocol:

   As evaluated, NetFlow v9 doesn't specify any security mechanisms.
   The IPFIX protocol specification must specify how the security
   requirements in section 6.3.3 of [1] can be assured.  The IPFIX
   specification must be specific about the choice of
   security-supporting protocol(s) and about all relevant issues such
   as security negotiation, protocol modes permitted, and key
   management.

   The other important requirement that isn't fulfilled by NetFlow v9
   today is support for a congestion-aware protocol (see section 6.3.1
   of [1]).  So a mapping to a known congestion-friendly protocol such
   as TCP, or, as suggested in [16], (PR-)SCTP, is considered as
   another necessary step in the preparation of the IPFIX
   specification.

These requirements are sort-of already in draft-ietf-ipfix-reqs, but
IESG feedback convinced me that it makes sense stating that in the
evaluation document too.

The text about security basically points out that "just use IPSec" is
NOT sufficient in a future IPFIX specification.  That was also an IESG
concern.

Other changes:

  Moved reference to draft-djernaes-netflow-9-transport from Normative
    to Informational
  IPSEC -> IPSec global replace
  Point out that DES (as used in LFAP's security mechanism) is
    considered inadequate today
  New boilerplate
-- 
Simon.

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