Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22
"Alexander Clemm" <ludwig@clemm.org> Wed, 24 April 2019 18:48 UTC
Return-Path: <ludwig@clemm.org>
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 C8D561201F8; Wed, 24 Apr 2019 11:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQycMOg4grZ0; Wed, 24 Apr 2019 11:48:38 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 1652F120100; Wed, 24 Apr 2019 11:48:37 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([73.189.160.186]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MNs0D-1hQnbX2FSd-007XFH; Wed, 24 Apr 2019 20:48:32 +0200
From: Alexander Clemm <ludwig@clemm.org>
To: 'Takeshi Takahashi' <takeshi_takahashi@nict.go.jp>, secdir@ietf.org
Cc: draft-ietf-netconf-yang-push.all@ietf.org, netconf@ietf.org
References: <155488041402.1083.9565126428194093115@ietfa.amsl.com>
In-Reply-To: <155488041402.1083.9565126428194093115@ietfa.amsl.com>
Date: Wed, 24 Apr 2019 11:48:30 -0700
Message-ID: <10a501d4face$513d3600$f3b7a200$@clemm.org>
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: <https://mailarchive.ietf.org/arch/msg/secdir/49WAsuVzZdiA7a2urMSV_rPbPZs>
Subject: Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: 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 <netconf-bounces@ietf.org> On Behalf Of Takeshi Takahashi via Datatracker Sent: Wednesday, April 10, 2019 12:14 AM To: secdir@ietf.org Cc: draft-ietf-netconf-yang-push.all@ietf.org; netconf@ietf.org Subject: [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22 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. </ALEX> 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 clarification. <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. </ALEX> 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. </ALEX> 4. security considerations (in section 7) This section enumerates four threats that are newly introduced by this draft. 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? </ALEX> _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf
- [secdir] Secdir last call review of draft-ietf-ne… Takeshi Takahashi via Datatracker
- Re: [secdir] [netconf] Secdir last call review of… Alexander Clemm