Re: [secdir] SECDIR review of draft-ietf-soc-load-control-event-package-11.txt

Volker Hilt <volker.hilt@bell-labs.com> Thu, 05 December 2013 14:08 UTC

Return-Path: <volker.hilt@bell-labs.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB471ADFF6; Thu, 5 Dec 2013 06:08:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTjVF-TF3vCk; Thu, 5 Dec 2013 06:08:49 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 10B391AE014; Thu, 5 Dec 2013 06:08:48 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rB5E8QKW007783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Dec 2013 08:08:26 -0600 (CST)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id rB5E8Olm017614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 09:08:25 -0500
Received: from [149.204.61.163] (135.5.27.17) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 5 Dec 2013 09:08:24 -0500
Message-ID: <52A088D5.1020804@bell-labs.com>
Date: Thu, 5 Dec 2013 15:08:21 +0100
From: Volker Hilt <volker.hilt@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Charles Shen <qs2005@columbia.edu>, Donald Eastlake <d3e3e3@gmail.com>
References: <CAF4+nEFOwAk4Ei9vd3GgsywmpSdzKfUD5EyOXwYmUMzMRkrSxw@mail.gmail.com> <CAPSQ9ZXP5nbZ+Uzk_3F29Pjp38BQqfYA=cV4MzwJZuEGdWm=Qw@mail.gmail.com>
In-Reply-To: <CAPSQ9ZXP5nbZ+Uzk_3F29Pjp38BQqfYA=cV4MzwJZuEGdWm=Qw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [135.5.27.17]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Mailman-Approved-At: Thu, 05 Dec 2013 06:14:26 -0800
Cc: "draft-ietf-soc-load-control-event-package.all@tools.ietf.org" <draft-ietf-soc-load-control-event-package.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-soc-load-control-event-package-11.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Thu, 05 Dec 2013 14:08:51 -0000

Charles,

Thanks for taking care of these comments!

Volker

On 04.12.2013 17:31, Charles Shen wrote:
> Hi Donald, thanks for reviewing, please see responses inline:
>
>
> On Tue, Dec 3, 2013 at 6:31 AM, Donald Eastlake <d3e3e3@gmail.com
> <mailto:d3e3e3@gmail.com>> 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.  Document editors and WG chairs should treat these comments just
>     like any other last call comments.
>
>     This draft provides SIP capabilities (a load control event package)
>     for filtering calls with the intent of better handling overload
>     conditions. As you might expect for an extension to an existing
>     protocol, there are many references to existing SIP RFCs.
>
>     The Security Considerations Section appears to be adequate. It
>     references RFCs 6665 and other sections of the draft and seems to
>     summarize relevant threats.
>
>     Minor points:
>
>     The introductions (Section 1) give examples of anticipatable and
>     unanticipatable causes of overload. I find it curious that denial of
>     service attacks are not listed as a possible cause of unanticipated
>     overload.
>
>
>
> Interestingly that thought occurred to me before. I think the ones we
> are listing now is slightly different from DoS in the sense that they
> are more real-people-calling overload vs. DoS where machine-made calling
> can be common. Also DoS is usually seen as an attack, while those listed
> examples seem all have legitimate causes. That said, I do think the
> network server still observes the fact of overload during DoS, so I have
> no problem adding it to the list.
>
>
>     In Section 10, in answer to REQ 17, there is a reference to Section 10
>     that, I believe, should be to Section 11.
>
>
> Good catch!
>
>
>     Editorial:
>
>     Section 4 begins with what is said to be a list of requirements. And I
>     think almost all of them are. But the first item is just not worded as
>     a requirement. It says "... we focus ...". To be a requirement on the
>     solution it should talk about the solution, not the authors. I think,
>     it should be more like "For simplicity, the solution should focus on a
>     method of controlling SIP load, rather than a generic application
>     layer mechanism."
>
>
> Done.
>
>     Misc:
>
>     The document contains lots of XML that I did not run through any
>     formal syntax check.
>
>
>
> I ran them through xmlvalidation.com <http://xmlvalidation.com>.
>
> thanks!
>
> Charles
>
>
>
>     Thanks,
>     Donald
>     =============================
>       Donald E. Eastlake 3rd +1-508-333-2270 <tel:%2B1-508-333-2270> (cell)
>       155 Beaver Street, Milford, MA 01757 USA
>     d3e3e3@gmail.com <mailto:d3e3e3@gmail.com>
>
>