Re: [Netconf] configured subscriptions over netconf and restconf

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Jul 20, 2018 at 01:02:55PM +0000, Kent Watsen wrote:
> 
> >> I believe the draft correctly explains the need for a client of a configured subscription to issue dynamic subscriptions.
> >> 
> > 
> > Not sure what you mean with this. Which section do you refer to?
> 
> I’m not looking at it right now, but I know that there’s a statement in the Security Considerations section. 
>

draft-ietf-netconf-netconf-event-notifications-10.txt:

10.  Security Considerations

   Notification messages (including state change notifications) are
   never sent before the NETCONF capabilities exchange has completed.

   If a malicious or buggy NETCONF subscriber sends a number of
   establish-subscription requests, then these subscriptions accumulate
   and may use up system resources.  In such a situation, subscriptions
   MAY be terminated by terminating the underlying NETCONF session.  The
   publisher MAY also suspend or terminate a subset of the active
   subscriptions on that NETCONF session.

   This draft has a YANG module which consists of a single identity.  As
   a result additional security concerns beyond those of the imported
   modules are not introduced.

The first paragraph is interesting but it is not clear why it is in
the security considerations. The second paragraph talks about a thread
but leaves out what happens to configured subscriptions created by a
malicious client. The last one says that the identity defined in the
YANG module has no security issues. The completeness of the security
considerations can perhaps be debated but anyway I see nothing
concerning "the need for a client of a configured subscription to
issue dynamic subscriptions".

Let me try draft-ietf-netconf-subscribed-notifications-14.txt. I find:

   With configured subscriptions, one or more publishers could be used
   to overwhelm a receiver.  Notification messages SHOULD NOT be sent to
   any receiver which does not support this specification.  Receivers
   that do not want notification messages need only terminate or refuse
   any transport sessions from the publisher.

So a notification receiver must implement
draft-ietf-netconf-subscribed-notifications-14.txt? How does the
server determine that the client did implement
draft-ietf-netconf-subscribed-notifications-14.txt?

   When a receiver of a configured subscription gets a new
   "subscription-started" message for a known subscription where it is
   already consuming events, the receiver SHOULD retrieve any event
   records generated since the last event record was received.  This can
   be accomplish by establishing a separate dynamic replay subscription
   with the same filtering criteria with the publisher", assuming the
   publisher supports the "replay" feature.

This is perhaps what you mean. But I wonder how this works for
transports that can't establish dynamic subscriptions. Note that this
is a SHOULD. Hence any transport SHOULD be able to create dynamic
subscriptions.

The more I look at these documents, the more questions pop up...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>