[secdir] Early secdir review of draft-clemm-netconf-yang-push-02 (draft-ietf-netconf-yang-push-00)

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Fri, 30 October 2015 03:18 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 74DD41B3575; Thu, 29 Oct 2015 20:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.497
X-Spam-Level: **
X-Spam-Status: No, score=2.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kRZ5ejUXEYzq; Thu, 29 Oct 2015 20:18:02 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB8A1B3574; Thu, 29 Oct 2015 20:18:01 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1.nict.go.jp []) by ns1.nict.go.jp with ESMTP id t9U3Hx0R063634; Fri, 30 Oct 2015 12:17:59 +0900 (JST)
Received: from mail1.nict.go.jp (mail1.nict.go.jp []) by gw1.nict.go.jp with ESMTP id t9U3HxDo063626; Fri, 30 Oct 2015 12:17:59 +0900 (JST)
Received: from VAIO (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 5DEBC3CA7; Fri, 30 Oct 2015 12:17:59 +0900 (JST)
From: "Takeshi Takahashi" <takeshi_takahashi@nict.go.jp>
To: <draft-ietf-netconf-yang-push.all@tools.ietf.org>
Date: Fri, 30 Oct 2015 12:17:57 +0900
Message-ID: <007301d112c1$93241aa0$b96c4fe0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdESwX8f3wXFpctfRJGGcvzjuzbYgw==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith1
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/eeKW1iclW4HoDtsHS7D6fwlbCqU>
Cc: iesg@ietf.org, netconf-chairs@tools.ietf.org, secdir@ietf.org
Subject: [secdir] Early secdir review of draft-clemm-netconf-yang-push-02 (draft-ietf-netconf-yang-push-00)
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 30 Oct 2015 03:18:03 -0000


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
Document editors and WG chairs should treat these comments just like any
other last call comments.

[overall feeling on this draft]

As an early review, this document is fine.
I believe the topic is very important.


This draft deals with the push mechanism of the YANG datastore's updats.
The usability of push mechanism is obvious.
The draft elaborates parameters needed for the mechanism, including filters
and subscription-config.


It was fun to read the article, though I am not that familiar with this

Here are several clarification questions.
I would appreciate if you could answer them to deepen my understanding.

Let me assue that I send a create-subscription message with the period=500
parameter. If the server can only send updates with period=1000, what will
Is the subscription declined? Or is the subscription accepted with

If it is declined, how can I know the supported period value?
I guess the error response message does not explain the minimum value for
the period.

I guess arbitrary value can be set for stop-time.
Then, the updates will be sent periodically for very long time, once the
subscription is accepted.
I am wondering if we need to check whether the subscriber is still alive
(whether the subscriber is still the authorized one).
Would you have any means to check the subscriber status ? (I guess no)
Or, do we need to specify stop-time that is not that far from now to avoid
any accident?

I am not sure how sensitive the update information is, so it could be a
nonsense question...

Are you going to use the IANA tables for the values, such as the "encoding"

Regarding the security consideration, I have got the impression that the
current text focuses on DDoS scenarios.
How about the false update?
Malicious entity may send false update to the subscriber.
The false update may let the subscriber mis-judge the situation and initiate
some operations.
Is it going to be a viable concern?

Thanks, and kind regards,