Skip to main content

Last Call Review of draft-ietf-ipfix-flow-selection-tech-
review-ietf-ipfix-flow-selection-tech-secdir-lc-harkins-2012-04-11-00

Request Review of draft-ietf-ipfix-flow-selection-tech
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-04-11
Requested 2012-04-03
Authors Salvatore D'Antonio , Tanja Zseby , Christian Henke , Lorenzo Peluso
I-D last updated 2012-04-11
Completed reviews Secdir Last Call review of -?? by Dan Harkins
Assignment Reviewer Dan Harkins
State Completed
Request Last Call review on draft-ietf-ipfix-flow-selection-tech by Security Area Directorate Assigned
Completed 2012-04-11
review-ietf-ipfix-flow-selection-tech-secdir-lc-harkins-2012-04-11-00
  Hello,

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  This draft describes techniques to select flows which are sets of
packets with some common characteristics. The authors have accurately
identified what constitutes an attack-- an adversary having the ability
to influence flow selection-- and the Security Considerations give
a couple examples of this. They seem fine.

  There is reference to a paper "[GoRe07]" which does not appear in the
References and seems to give advice that I think is wrong: use a strong
cryptographically strong random number generator to thwart an attack in
which parameters of time-based sampling are discovered to predict the
selection decision. This attack can be thwarted by using a value that
the adversary cannot predict (sort of like an IV for CBC mode) instead
of a cryptographically strong random number. That leaves the random
number pool to applications that really need it (like a key exchange
that does a Diffie-Hellman). I suggest removing the reference to the
un-referenced paper and mention a weaker requirement to thwart that
attack.

  regards,

  Dan.