Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT)
"Adrian Farrel" <afarrel@juniper.net> Mon, 09 April 2012 19:54 UTC
Return-Path: <afarrel@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A557E21F87F4; Mon, 9 Apr 2012 12:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpVRBY-Pms9X; Mon, 9 Apr 2012 12:54:05 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6E21F87EA; Mon, 9 Apr 2012 12:54:04 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q39JrtLE021935; Mon, 9 Apr 2012 20:53:59 +0100
Received: from 950129200 (AGrenoble-551-1-55-195.w86-197.abo.wanadoo.fr [86.197.14.195]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q39JrhAS021876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Apr 2012 20:53:50 +0100
From: Adrian Farrel <afarrel@juniper.net>
To: 'Al Morton' <acmorton@att.com>, adrian@olddog.co.uk, 'Samuel Weiler' <weiler@watson.org>, 'The IESG' <iesg@ietf.org>
References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> <201204080018.q380I1VK007743@alpd052.aldc.att.com> <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> <201204091344.q39Di1rK002725@alpd052.aldc.att.com>
In-Reply-To: <201204091344.q39Di1rK002725@alpd052.aldc.att.com>
Date: Mon, 09 Apr 2012 20:53:45 +0100
Message-ID: <0bea01cd168a$7ed8ae80$7c8a0b80$@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIbFLUL4L9fmeWqHCNmPVdbYjLawgGKVkKaAd6sRCwBimPGyQGdYPqzAfLYlEKVsqa4AA==
Content-Language: en-gb
X-Mailman-Approved-At: Tue, 10 Apr 2012 08:03:48 -0700
Cc: ippm-chairs@tools.ietf.org, draft-ietf-ippm-rt-loss@tools.ietf.org, 'Dan Frost' <danfrost@cisco.com>, "'Murphy, Sandra'" <Sandra.Murphy@sparta.com>, secdir@ietf.org
Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: afarrel@juniper.net
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 19:54:06 -0000
Al, As always, a reasoned response from you. A > -----Original Message----- > From: Al Morton [mailto:acmorton@att.com] > Sent: 09 April 2012 14:45 > To: adrian@olddog.co.uk; 'Samuel Weiler'; 'The IESG' > Cc: secdir@ietf.org; 'Murphy, Sandra'; 'Dan Frost'; ippm-chairs@tools.ietf.org; > draft-ietf-ippm-rt-loss@tools.ietf.org > 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
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Al Morton
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Adrian Farrel
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Al Morton
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Adrian Farrel
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Al Morton
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Adrian Farrel
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Benoit Claise
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Wesley Eddy
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Murphy, Sandra
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Stephen Farrell
- Re: [secdir] Adrian Farrel's Discuss on draft-iet… Al Morton