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

["Adrian Farrel" <[e-mail]>]

Al,

As always, a reasoned response from you.

A

> -----Original Message-----
> From: Al Morton [mailto:[e-mail]]
> Sent: 09 April 2012 14:45
> To: [e-mail]; 'Samuel Weiler'; 'The IESG'
> Cc: [e-mail]; 'Murphy, Sandra'; 'Dan Frost';
[e-mail];
> [e-mail]
> Subject: RE: Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with
DISCUSS
> and COMMENT)
> 
> 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
> 
> 
> At 02:04 PM 4/8/2012, Adrian Farrel wrote:
> >Hello Al,
> >
> > > > > 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.
> > > >
> > > >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.
> > >
> > > 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.
> >
> >OK. I cleared my Discuss.
> >
> > > > > > > 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.
> > > >
> > > >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.
> > >
> > > 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?
> >
> >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
> > >     was generated fast enough for the intended purpose
> >
> >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