Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

[Balázs Lengyel <[e-mail]>]

Hello Rob,

See below. I only kept the parts we are discussing. I will answer model related issues in a separate mail.

Regards Balazs

 

From: Rob Wilton (rwilton) <[e-mail]> 
Sent: 2019. október 3., csütörtök 18:13
To: Balázs Lengyel <[e-mail]>; Mahesh Jethanandani <[e-mail]>; Netconf <[e-mail]>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

 

Hi Balazs,

In section 3, I think 

 

   The information SHALL be provided in two ways both following the

   ietf-notification-capabilities module:

 

should be:

 

   The information SHOULD be provided in two ways both following the

   ietf-notification-capabilities module:

BALAZS2: OK. But in this case I will need to use SHOULD in the following 2 bullets too.

 

 

-        Is “max-objects-per-update” optional.  What if the server doesn’t have any hard limit - can they just not return a value here?  If so, perhaps assigning a default value of uint32_max might make sense?

BALAZS: It is optional. If there is no hard limit or the limit is not known the leaf must be absent. The module description include the text:

      Any capability value MAY be absent ... if the publisher is not capable of 

      providing a value.

[RW] 

OK.  Then I think that there should be a bit more text about what values mean if they are not specified.  E.g. perhaps the following (if this is the right behaviour for all properties).

 

Old:

      Any capability value MAY be absent if a more generic capability

      value is already provided or if the publisher is not capable of

      providing a value.

 

New:

      Any capability value MAY be absent if a more generic capability

      value is already provided or if the publisher is not capable of

      providing a value.  If not provided then it should be

      interpreted that the property is unconstrained. 

BALAZS2: Don’t agree. Someone requested earlier and I agreed, that there is a use case where there is actually a limit, just it is not known, or not easily calculated, or changing during time. Anyway IMHO specifying unlimited is not really meaningful. Nothing is unlimited in reality. Also it is explicitly stated that the publisher is allowed to limit individual subscriptions to a lower throughput.

So my view is that if we don’t have a value that means nothing more than that we could not provide a meaningful limit.

 

 

In the security section, are these capabilities sensitive information?  E.g. could it be used by an attacker to more effectively DDOS a server (by knowing which paths to target subscriptions towards)?

BALAZS: IMHO the information is not security sensitive. The minimum dampening period and minimum-update-period can be used to find schema sections that might generate more notifications, but this is really a corner-case and we usually don’t describe such details. However the security section now includes:

         The Network Configuration Access Control Model (NACM) [RFC8341] 

         provides the means to restrict access for particular NETCONF or 

         RESTCONF users to a preconfigured subset of all available NETCONF or 

         RESTCONF protocol operations and content. 

         If access control is not properly configured, it can expose

         system internals to those who should not have access to this

         information.

[RW] 

Thinking about this some more, I wonder whether the security section could/should refer back to YANG-Push, which allows a server to reject subscriptions if it would cause the server to become overloaded.

BALAZS2: Kent wanted just to state, not modifiable, not sensitive. I updated this to: 

      All protocol-accessible data are read-only and cannot be modified. 

        The data in this module is not security sensitive.

        Access control may be configured, to avoid exposing 

        the read-only data.

When that data is in file format, data should be protected against 

        modification or unauthorized access using normal file handling and 

        secure and mutually authenticated file transport mechanisms.

I hope that will be OK

 

Thanks,

Rob

 

 

Thanks,

Rob