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

From: Al Morton <[email-masked]>
Date: Fri, 06 Apr 2012 11:54:19 -0400

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Apr 2012 18:02:17 +0100

Hi Al,

Thanks for the response.

> and improve the text, rather than be referred to a fixed reference.

I can see how that would lead to the verbatim reproduction of text. I have no
problem with that per se, but I worry that the process has become formulaic
without any new consideration of security for the specific document in hand. 

If you tell me that this is adequate for this document and no refinement is
needed in this case, I will clear and let the Security ADs and Directorate worry
about the security details.

> New paragraph addresses Sandy and Dan's points.

Thanks.

> dating back to TWAMP's development.  We wear the scar proudly.

Well, this is only a Comment, and you do not have to address it, but "as
immediately as possible" is hogwash. It is a butchery of the language and means
nothing!  

In fact, and as a general principle of writing standards, even "as quickly as
possible" would be poor. The English would be fine, but it is a subjective
statement against which conformance cannot be measured.

> thanks for pointing out the above.

Cheers,
Adrian

---

From: Al Morton <[email-masked]>
Date: Sat, 07 Apr 2012 20:19:04 -0400

Hi Adrian,

Thanks for your reply.
We've narrowed the discussion down to two issues.
see below,

>about the security details.

I think it is. We are essentially conducting a two-way version of RFC 2680
(one-way loss), so all the same considerations apply. We have exposure in
two (possibly different) paths, but the threats are the same.

>...

Under typical protocol development circumstances, we could write a
real requirement:
         The response MUST be prepared and sent on the wire in <X seconds.

But that's not the case here.  Instead we have desire that the response
will be sent immediately, yet we understand that measurement systems will:

  - occasionally execute higher priority processes that delay the response
    (processing routing updates comes to mind)
  - carry 2 time stamps that allow the tester to determine if the response
    was generated fast enough for the intended purpose
  - serve purposes with greater or lesser need for immediacy
  - either meet the variable needs for measurement immediacy or not, and
    this is a judgement that can be made on each and every measurement packet

Is it useful to explain some/all of this in the memo?

regards,
Al

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 8 Apr 2012 19:04:01 +0100

Hello Al,

> two (possibly different) paths, but the threats are the same.

OK. I cleared my Discuss. 

> Is it useful to explain some/all of this in the memo?

I don't think so. I would just fix the text to say what you mean!

I found key text in your mail to be:

>     allow the tester to determine if the response

Surely it is not enough to have the tester discard all response because they
were not fast enough. Surely it is a good idea to give *meaningful* advice to
the responder about how to respond so that the response is "fast enough for the
intended purpose."

Clearly "immediately" is not what is meant since it is allowed for this to be a
background process. So perhaps the correct thing to do is warn the implementer
of the responder about the expectations of the tester. Something like:

A tester will normally find that a response that was not generated within 3
weeks is inadequate for the purposes of a realistic test and will discard such
responses. Therefore, a responder needs to ensure that at least 67.2% of
responses are generated within 1 hour of receiving the request. A responder that
is unable to satisfy this requirement SHOULD log the fact so that an operator
can adjust the load and priorities as necessary. A tester that finds that
responses regularly are not generated in a timely fashion SHOULD notify the
operator that the responder is compromising the tests, and SHOULD suspend
sending requests to the responder since it is clearly overloaded.

Ciao,
Adrian

---

From: Al Morton <[email-masked]>
Date: Mon, 09 Apr 2012 09:45:09 -0400

Hi Adrian,

Thanks for clearing your DISCUSS. As always, the memo reads better
owing to your efforts, and those of Dan and Sandra.

Here's what I added in section 4.4, with supporting modifications
elsewhere:

We add the following guidance regarding the responder process to
"send a Type-P packet back to the Src as quickly as possible".

A response that was not generated within Tmax is inadequate for any 
realistic test, and the Src will discard such responses. A responder 
that serves typical round-trip loss testing (which is relevant to 
higher-layer application performance) SHOULD produce a response in 1 
second or less. A responder that is unable to satisfy this 
requirement SHOULD log the fact so that an operator
can adjust the load and priorities as necessary. Analysis of 
responder time-stamps [RFC5357] that finds responses are not 
generated in a timely fashion SHOULD result in operator notification, 
and the operator SHOULD suspend tests to the responder since it may 
be overloaded. Additional measurement considerations are described in 
Section 8, below.

Ciao,
Al

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Apr 2012 20:53:45 +0100

Al,

As always, a reasoned response from you.

A

> -----Original Message-----
> From: Al Morton [mailto:[email-masked]]
> Sent: 09 April 2012 14:45
> To: [email-masked]; 'Samuel Weiler'; 'The IESG'
> Cc: [email-masked]; 'Murphy, Sandra'; 'Dan Frost';
[email-masked];
> [email-masked]
> Subject: RE: Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with
DISCUSS
> and COMMENT)

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Apr 2012 14:28:14 +0200

Al, Wes

I want to review this draft before the IESG telechat tomorrow.
However, it's getting difficult to keep track of the all the changes between
     - the posted version 3
     - the diff-03-04 you sent
     - the extra proposal.

What is the best way to proceed?
     - Al, have you kept a temp version with all the changes?
     - Are we shooting for "revised-ID" at the telechat? I could start 
my review from there
     - Do we want to have a version 4 posted now?

What is the best way to proceed?

Regards, Benoit.
>>>>           The response MUST be prepared and sent on the wire in<X seconds.
>>>>

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 11 Apr 2012 14:11:56 -0400

On 4/11/2012 8:28 AM, Benoit Claise wrote:
>     - Are we shooting for "revised-ID" at the telechat? I could start my
> review from there

I noticed Al sent a copy with updates that have been suggested
so far.

Please feel free to hit the "Defer" button if you don't feel
there's adequate time to review this one; it looks like a busy
telechat agenda this week!

-- 
Wes Eddy
MTI Systems

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 12 Apr 2012 16:19:56 +0000

Dan Frost and I brought up some of the same comments, wrt the active or passive use of the metric and the suggestion of cryptographic hashes to solve security considerations.

The latest revision satisfies me.

There's one question I'm not adequate to address, and I leave it to the authors and ADs to address:

   Although this metric MAY be applicable in
   passive measurement as well, discussion of additional considerations
   for the passive scenario are beyond the normative scope of this memo.

Does that "MAY" mean "optional" in the 2119 sense, or "might"/"could" in normal English usage sense?  

It sounds like this is saying "there are considerations if this metric is used in a passive scenario, which we aren't going to discuss, but even so you have the option to use this".

I don't know what the "additional considerations" would be.  If they are considerations that a measurement implementer should heed, that's not much of a worry.  If they are considerations that impact others, that's more of a worry.  (Section 9.2's discussion of keeping info confidential (for passive measurements) is an example of considerations that impact others.) 

So I'll leave it to those who know whether that "MAY" is OK or not.

--Sandy 

________________________________________
From: Wesley Eddy [[email-masked]]
Sent: Wednesday, April 11, 2012 2:11 PM
To: Benoit Claise
Cc: [email-masked]; 'Al Morton'; [email-masked]; 'Samuel Weiler'; 'The IESG'; [email-masked]; [email-masked]; 'Dan Frost'; Murphy, Sandra; [email-masked]
Subject: Re: Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03:     (with DISCUSS and COMMENT): new (temp) draft?

--
Wes Eddy
MTI Systems

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Apr 2012 17:21:12 +0100

Thanks Sandy,

I've cleared.

S