Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22

"Alexander Clemm" <> Wed, 24 April 2019 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8D561201F8; Wed, 24 Apr 2019 11:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TQycMOg4grZ0; Wed, 24 Apr 2019 11:48:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1652F120100; Wed, 24 Apr 2019 11:48:37 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([]) by (mreueus003 []) with ESMTPSA (Nemesis) id 0MNs0D-1hQnbX2FSd-007XFH; Wed, 24 Apr 2019 20:48:32 +0200
From: "Alexander Clemm" <>
To: "'Takeshi Takahashi'" <>, <>
Cc: <>, <>
References: <>
In-Reply-To: <>
Date: Wed, 24 Apr 2019 11:48:30 -0700
Message-ID: <10a501d4face$513d3600$f3b7a200$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGkXl6tnNmJZ5U6rvHBJnkUSxkaRKaszf2w
Content-Language: en-us
X-Provags-ID: V03:K1:nuJdqaepsb4NRn/yC+/vgYtPBnm2jf3YLRt+25/hlOJ1v54mq9e 5y3vAH9ZOPPP8jN9rPg2WrApUvytWaxajyX7Fw5moRjjKd9G5mSZpPtpNLp36IAc86iOvYK YlBX7s9lOsGkFH259Wgqd5Hq37NTy91fRrGrPspX6LshWG+0fIIGRREQjptZ8n3Q2K/jA4+ iNWNp9kl/1c1fbySmK/wQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:eVc5fBhcLhM=:TQC8pC0+otFfJYgJ9ffzUD NbKtjF6cf6tckragEXGJZWlnve/JbbVpJwHuIVkx9Op4BYGbKXa8WEW7brgAZMtnUPZ7tCDKJ H01ETGIr+DpCXP7GVLbaAfCrir3ZR8z/1rlKIN7m5gWbfX5UpFvaYUNBujQaE+xDpOJc2u+AH 3RLre7TxbGAXw8PnVLyXzUwHm+/p4BUBcmA9z9REAQ2Do+xRAO9I3keqZmKu/trnYHkgbdtTQ v0kTAlvqE65pb03Ra3OTHGdp167ZH7dck/j1sQYvPpMnyJae6xLU4yy8JH4TGZ45sSwXOi/ED KfXnSDiRYhEyWTn2CZizE1eUuzCGrnaZuvDaUDYE55t+3684dZ3WHd2UHLhvQv9bpPZ7L6FIu Z4ZDsOd5+oJ/xmBGYxQIU7oRe1DDEn8W5Fwc9Uz5WqRKTR1eOo1ZK0gKStPDuDHYvGYfpakPC bmOmCd/llq+NhxEccrN2EVamzHSPwoRbjzPi0rYa7CPo8zzCGDic+OPI7qB/+4O/wIUj8UDMc h0RMxghrIEwWaobki0eRITrjrfPdh3JJLL00Fi49V4M+aRbDpwpwS0f1MHJ4h+yUFjhnT5vB3 OtkqBiyklABiGadYaCPFqu3bsWK0cXzXacitHTYODRU5WxFrSwTH1Eoz1P47hF53s9dvmkr6z 2emBASd2GiAhaFPfp9VwZKBVj3QoudGUO0LFBXm4SFNMvX0fTUah0Vawgg66umkaOl1X+NIWB 7NK/+CWCzgKsYC08rG4RotzrflKVMmlYHKktoCV5f/Wta8jlVgXALgnh3T8=
Archived-At: <>
Subject: Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Apr 2019 18:48:41 -0000

Hi Takeshi,

Thank you for your review!  Please see replies inline, <ALEX>

--- Alex

-----Original Message-----
From: netconf <> On Behalf Of Takeshi Takahashi via
Sent: Wednesday, April 10, 2019 12:14 AM
Subject: [netconf] Secdir last call review of

Reviewer: Takeshi Takahashi
Review result: Has Nits

This draft talks about push-type update notifications of YANG datastore. It
provides two types of subscriptions: periodic and on-change. I have one
comments (item 4) and four clarification questions (items 1-3) below.

1. on the on-change subscription (in sections 3.3 and 3.10)

The draft says "it will be important for client applications to have a way
to identify for which objects on-change notifications are supported and for
which ones they are not supported," but this issue is currently left to the
implementation. It would be nice if you could provide some example solutions
to this problem so that the implementers of this draft will not be confused.

When a publisher accept on-change subscription even when the scope of the
subscription contains objects for which on-change is not supported, I wonder
sending some notification message on the situation could be helpful for the
subscriber. By reading other part of the draft, I feel that the draft is
indeed recommending to implement such comprehensive notifications. If so, it
had better be clearly mentioned in this section. I also think it is not a
bad idea to define such a comprehensive notification in this draft, though
it is up to the authors.

<ALEX> Because the solution to the topic of knowing for which objects
on-change notifications are supported is indeed complex, this is actually
being deferred to a different draft,
draft-ietf-netconf-notification-capabilities, which allows a subscriber to
precisely discover where this is supported and where not.   As to what to do
when a subscription's scope contains objects not capable of on-change
notifications,  section 3.3 states "Whether or not to accept or reject
on-change subscription requests when the scope of the subscription contains
objects for which on-change is not supported is up to the publisher
implementation."  There are no separate notifications that will be sent;
instead this is handled through replies to the request.  Notifications are
only sent when the state of the subscription changes, which would include
scenarios in which the server decides it can no longer support the
subscription (due to dynamic changes, or whatever) after all.  

2. on the differing dampening periods for multiple objects(in section 3)

The draft says "In case whether a subscriber wants to have separate
dampening periods for different objects, the subscriber has the option to
create multiple subscriptions with different selection filters." That is a
good solution. Then are the any other options for allowing to have separate
dampening periods for different objects? The sentence gave me the impression
that there are multiple options; so I am asking this question only for

<ALEX> No, this is the only option.  Within a subscription only one
dampening period applies.  Anything else would make configuration and
figuring out what is going on super complex.  Hence the solution of applying
separate subscription if an application indeed requires different settings
for different subscribed objects.  

3. imcomplete-update flag (in sections 3.11.1 and 4.3.2)

I am not sure what would be the expected actions of the subscribers when
they receive a message with incomplete-update flag on. Some navigations
would be appreciated. Meanwhile, according to section 4.3.2, a publisher MAY
subsequently send a push-update containing a full selection snapshot of
subscribed data. If such a push-update is subsequently sent, does the
publisher need to send anoter message with incomplete-update flag on prior
to the push-update with a full selection snapshot of subscribed data?

<ALEX> When a message with an incomplete-update flag is received, what it
will do is really up to the receiver.  Really, the flag is there only for
exceptions to let the receiver know if due to some unforeseen and
unavoidable circumstance the server is not able to fulfill its obligation
per the terms of the subscription.  

The actual exception handling that a receiver application would apply when
receiving a push-update with an incomplete flag depends on the application.
A receiver could choose to resynch (retrieving all subscribed information).
It could choose to wait (some applications may be okay with the loss of some
information, but at least they know).  It could choose to tear down the
subscription and start a new one, perhaps with a lesser scope.   We will add
this sentence to make this clear; will this address your concerns?

I am not clear on the second part of your question regarding sending another
message with incomplete flag.  The goal of the push-update with a full
selection snapshot of subscribed data is to make sure that the receiver is
again in sync with the subscribed data; only if for some reason that would
fail (and be incomplete again) an incomplete flag would be set.  Obviously,
if there are continuous problems (i.e. incomplete-update occurs all the
time, no resync possible), this constitutes an error condition; the
publisher may suspend the subscription in this case (as stated) and the
subscribing application may decide that the subscription of the publisher
are useless.  

4. security considerations (in section 7)

This section enumerates four threats that are newly introduced by this
Some countermeasures, or directions to address these threats, had better be
provided here.

<ALEX> Not exactly sure what to put here.  We do mention that NACM should be
used to restrict access.  
Since most of the attacks involve modifying the terms of the subscription,
we can add a sentence to the effect of:  
"A subscriber could monitor the subscription configuration itself for any
unexpected changes.  For this, they should monitor notifications regarding
updates to their subscriptions to validate that these updates were indeed
intended.  They could even subscribe to updates to the YANG datastore nodes
that represent their datastore subscriptions."  
Will this address your concern?  

netconf mailing list