Re: [ippm] Adam Roach's Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Mon, 02 July 2018 18:32 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054DD130E08; Mon, 2 Jul 2018 11:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Level:
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ZsrEfksismmN; Mon, 2 Jul 2018 11:32:23 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3CC130F46; Mon, 2 Jul 2018 11:32:23 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w62IWD4t057146 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 2 Jul 2018 13:32:16 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ippm-twamp-yang@ietf.org, Nalini Elkins <nalini.elkins@insidethestack.com>, ippm-chairs@ietf.org, ippm@ietf.org
References: <152955610162.28620.13249468338471662781.idtracker@ietfa.amsl.com> <063FD288-AF03-43B0-A519-5BFE418D3DC0@gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <8a7069c7-c818-2b47-edd6-431fa98af0fb@nostrum.com>
Date: Mon, 02 Jul 2018 13:32:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <063FD288-AF03-43B0-A519-5BFE418D3DC0@gmail.com>
Content-Type: multipart/alternative; boundary="------------64AB1E25FC67FEB153A4B87F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/2C6zKw36ZewRDOsKIzK1qd0kzmI>
Subject: Re: [ippm] Adam Roach's Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jul 2018 18:32:26 -0000

Thanks for addressing the various comments I made -- your resolutions 
all seem good to me. One comment on the security section, below:

On 6/22/18 2:14 PM, Mahesh Jethanandani wrote:
> ----------------------------------------------------------------------
>> Thanks for the work and thought that everyone involved in this document spent. I
>> find the model well described and easy to understand.
>>
>> I agree with Ben's comments about including more information about the privacy
>> and security properties of specific entities in the module. See
>> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines for specific
>> guidance.
>>
>> Since this conflicts with normative language in RFC 6087 §3.4 (and 6087bis
>> §3.7), it is a blocking defect that needs to be remedied prior to publication.
> I have added more nodes in the Security Considerations section.

Thanks. This is an improvement, but I'm still a bit concerned about the 
fact that the section speaks only in examples ("examples include" and 
"nodes such as") rather than explicitly identifying sensitive nodes, 
which is what I believe RFC 6087 anticipates. I also don't think that 
simply stating that the attacks that result from changing certain 
parameters "are obvious" is enough to satisfy either the spirit or 
letter of what is intended by:

>     In particular, writable data nodes that could be especially
>     disruptive if abused MUST be explicitly listed by name and the
>     associated security risks MUST be spelled out.
>

/a