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

["Alexander Clemm" <[e-mail]>]

Hi Takeshi,

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

--- Alex

-----Original Message-----
From: netconf <[e-mail]> On Behalf Of Takeshi Takahashi via
Datatracker
Sent: Wednesday, April 10, 2019 12:14 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf