Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT)

[Al Morton <[e-mail]>]

Hi Adrian and Sam,

This preliminary revision of the -rt-loss-draft addresses
DISCUSSes, Comments, Rtg-area and sec-dir reviews.
The diff to 03 and 04 prelim are attached.

Also, see replies below (to both Adrian's and Sandy's messages).

regards,
Al

At 10:44 AM 4/6/2012, Adrian Farrel wrote:
>Adrian Farrel has entered the following ballot position for
>draft-ietf-ippm-rt-loss-03: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>The Routing Diretorate review by Dan Frost missed the IETF Last Call
>period by two days, but I would like the following points from his
>review to be considered as part of this Discuss. Other smaller issues
>are recorded as Comments.
>
> > General observation: It's not clear to me what the IPPM WG strategy
> > is for security considerations sections in metric definition
> > documents.  For example, the security section of this document more or
> > less repeats the one in (for example) RFC 2681, which itself
> > duplicates verbatim the one in RFC 2680, and the issues discussed are
> > general ones with measurement protocols rather than specific ones with
> > the metric that is the subject of the document.  There's probably a
> > better way to organize this.

Although IPPM has never formalized a strategy, we have been repeating
security material in metrics RFCs. This allows new folks to read
and improve the text, rather than be referred to a fixed reference.
It seems to work.



> > 3. Section 9.3 mentions the use of cryptographic hashing "to
> > discourage the kind of interference mentioned above"; while this
> > would mitigate the second form of interference, it wouldn't help
> > with the first.
>
>I would add that "discourage" might not be an appropriate word.

New paragraph addresses Sandy and Dan's points.



>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>Other comments coming from Dan Frost's review
>
> > 1. Although it's probably obvious to most readers, it would be helpful
> > to provide a brief informal definition of "round-trip loss" early in
> > the introduction.  A mention of the venerable "ping" procedure would
> > also not be amiss.

Did both.


> > 2. Most of the text seems to assume an "active" or test-based
> > measurement approach, but Section 9.2 refers to passive measurement.
> > It would be helpful to discuss the applicability of the latter
> > approach.

Clarified the scope for passive.


> > Nits:
> >
> > 1. The phrase "as immediately as possible" that appears a couple of
> > times in the text (and that seems to originate in RFC 5357) is a bit
> > unfortunate.  "Immediately" or "as quickly as possible" are better.

This odd turn of phrase resulted from many hours of discussion
dating back to TWAMP's development.  We wear the scar proudly.

> >
> > 2. Section 5.4, second paragraph: s/affects/effects/
> >
> > 3. Section 8, second paragraph: s/Two key features ... is described/
> >  Two key features ... are described/
> >
> > 4. Section 9.3, first paragraph:
> > OLD
> >  it is possible to change the processing of the packets (e.g.
> >  increasing or decreasing delay) that may distort the measured
> >  performance.
> > NEW
> >  it is possible to change the processing of the packets (e.g.
> >  increasing or decreasing delay) in a way that may distort the
> >  measured performance.
> > END

thanks for pointing out the above.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

At 01:23 PM 3/15/2012, Murphy, Sandra wrote:
>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?

Yes, but it is beyond the scope for adding the many additional considerations
needed when using a passive scenario. However, we leave the door open
to do this work in the future.


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

Yes, as you point out:

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

The new paragraph mentions TWAMP as well, but it is only one of many
protocols that can/will make this measurement.


>--Sandy