Last Call Review of draft-ietf-ippm-rt-loss-
review-ietf-ippm-rt-loss-secdir-lc-murphy-2012-03-16-00

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.

The draft-ietf-ippm-rt-loss-03 draft defines a round trip loss metric.  A round
trip loss measurement capability is specified in RFC5357 ("Two-Way Active
Measurement Protocol (TWAMP)"), but no metric has been defined in the defined
RFC2330 framework.

As this draft defines a new metric, not the means to implement measurements
with the metric, I do not see that security considerations apply.  But I see no
problem with discussion of the considerations that should guide implementations.

(Indeed, RFC2861 which defines a delay metric says much the same:
   Conducting Internet measurements raises both security and privacy
   concerns.  This memo does not specify an implementation of the
   metrics, so it does not directly affect the security of the Internet
   nor of applications which run on the Internet.  However,
   implementations of these metrics must be mindful of security and
   privacy concerns.)

I have a few comments about the security considerations section.

The section mentions both active and passive use of the metric.  But the
abstract and intro imply this metric is for use in TWAMP, which is active.  Is
use of the metric possible in passive measurements as well?

In section 9.3, it says:

   It may be possible to identify that a certain packet or stream of
   packets is part of a sample.  With that knowledge at the destination
   and/or the intervening networks, it is possible to change the
   processing of the packets (e.g. increasing or decreasing delay) that
   may distort the measured performance.  It may also be possible to
   generate additional packets that appear to be part of the sample
   metric.  These additional packets are likely to perturb the results
   of the sample measurement.

   To discourage the kind of interference mentioned above, packet
   interference checks, such as cryptographic hash, may be used.

How would a simple crypto hash prevent either the distortion of performance
(delaying a packet will not change its hash) or the injection of additional
packets (a cryptographic hash can be computed for the injected packets as well).

RFC2861 mentions similar injection concerns and recommends:

                   Authentication techniques, such as digital signatures, may
   be used where appropriate to guard against injected traffic attacks.

Is there reason to suggest authentication in this metric definition as well? 
TWAMP provides (but does not mandate) both authentication and encryption.  If
TWAMP is the only use of the metric, those features should be mentioned.  If
TWAMP is just one important use of the metric, it could be good to mention the
features here.

--Sandy