Subject: [Netconf] draft-ietf-netconf-rfc6536bis Query

From: Rohit R Ranade <[email-masked]>
Date: Thu, 1 Feb 2018 11:35:11 +0000

Hi All,

Q1:
In the notification authorization Section 3.4.6 there is mention that REPLAY notifications should be allowed by default.
But there is no mention of how to handle <create-subscription> operation authorization which can trigger these Replay notifications ? Since there is no module defined for it, there is no way to add a rule for permitting or denying it.

1.       How do the current NACM implementations handle it ? Allow <create-subscription> if exec-default is PERMIT ? or always allow <create-subscription> ?

Q2: If there is an error of access-denied for edit-config operation, does the RFC restrict from outputting the <error-path> of the data-store node for such operations ?
Section 3.2.5 has "   The contents of specific restricted datastore nodes MUST NOT be

   exposed in any <rpc-error> elements within the reply." , what is the meaning of 'content' here ? the schema-name of the leaf / key-values of data-store-nodes ?

Since the user has inputted the keys for the data-store nodes is there any security risk in giving back the values to the user ?

With Regards,
Rohit R

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Feb 2018 14:35:03 +0100 (CET)

Hi,

Rohit R Ranade <[email-masked]> wrote:
> Hi All,
> 
> Q1:
> In the notification authorization Section 3.4.6 there is mention that
> REPLAY notifications should be allowed by default.

I think you mean <replay-complete>.   Replayed notifications in
general are not allowed by default.

> But there is no mention of how to handle <create-subscription>
> operation authorization which can trigger these Replay notifications ?
> Since there is no module defined for it, there is no way to add a rule
> for permitting or denying it.
> 
> 
> 1.  How do the current NACM implementations handle it ? Allow
> <create-subscription> if exec-default is PERMIT ? or always allow
> <create-subscription> ?

I had to check, and our implementation matches create-subscription if
the module-name in the rule is "*".

I think some implementations use an internal (non-standard) YANG
module name for the model in RFC 5277, so they presumably match if
that internal module name is given, or "*".

> Q2: If there is an error of access-denied for edit-config operation,
> does the RFC restrict from outputting the <error-path> of the
> data-store node for such operations ?
>    exposed in any <rpc-error> elements within the reply." , what is the
>    meaning of 'content' here ? the schema-name of the leaf / key-values
>    of data-store-nodes ?
> 
> Since the user has inputted the keys for the data-store nodes is there
> any security risk in giving back the values to the user ?

3.4.3 also has

   A server MUST NOT include any information the client is not allowed
   to read in any <error-info> elements within the <rpc-error> response.

/martin

---

From: Rohit R Ranade <[email-masked]>
Date: Mon, 5 Feb 2018 07:16:32 +0000

Hi Martin,

There are around 6-7 places in the BIS and RFC 6536 where the term " datastore node" is used. It is unclear what is the meaning of this term as it is not defined in the Terminology section and it is unclear what is the difference between this term and "data node". Please clarify

For example: In section 3.2.3

   The contents of specific restricted datastore nodes MUST NOT be
   exposed in any <rpc-error> elements within the reply.

With Regards,
Rohit R

-----Original Message-----
From: Rohit R Ranade 
Sent: 02 February 2018 15:19
To: 'Martin Bjorklund' <[email-masked]>
Subject: RE: [Netconf] draft-ietf-netconf-rfc6536bis Query

Ok. 

With Regards,
Rohit R

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]]
Sent: 02 February 2018 15:17
To: Rohit R Ranade <[email-masked]>
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Query

Hi,

Rohit R Ranade <[email-masked]> wrote:
> Hi Martin,
> 
> Should we not be specific in the DRAFT about how to handle 
> <create-subscription> rpc like we have done for the replay control 
> notifications ?

The control notifications are treated differently b/c they are control notifications, not b/c they are not defined in a YANG module.

I think you have a valid point; however, since the WG is currently defining new operations that will replace the old <create-subscription>, I think this problem will go away.

Also, 6536bis is in the RFC editor queue, so changing in 6536bis this is quite problematic.

/martin

> Else each device will have its own mechanism of access control for 
> <create-subscription>.
> 
> With Regards,
> Rohit R
> 
> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: 01 February 2018 19:05
> To: Rohit R Ranade <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Query
> 
> Hi,
> 
> > In the notification authorization Section 3.4.6 there is mention 
> > that REPLAY notifications should be allowed by default.
> 
> > Since there is no module defined for it, there is no way to add a 
> > rule for permitting or denying it.
> > 
> > 
> > Since the user has inputted the keys for the data-store nodes is 
> > there any security risk in giving back the values to the user ?
> 
> 3.4.3 also has
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Feb 2018 09:49:36 +0100 (CET)

Hi,

Rohit R Ranade <[email-masked]> wrote:
> Hi Martin,
> 
> There are around 6-7 places in the BIS and RFC 6536 where the term "
> datastore node" is used. It is unclear what is the meaning of this
> term as it is not defined in the Terminology section and it is unclear
> what is the difference between this term and "data node". Please
> clarify

Is the term "datastore node" really unclear?  Would a defintion "a
node in a datastore" help  (I think it would be a tautology).

The term "data node" is imported from RFC 7950.

/martin

> The control notifications are treated differently b/c they are control
> notifications, not b/c they are not defined in a YANG module.
> 
> I think you have a valid point; however, since the WG is currently
> defining new operations that will replace the old
> <create-subscription>, I think this problem will go away.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Feb 2018 11:01:17 +0100 (CET)

Hi,

Rohit R Ranade <[email-masked]> wrote:
> Hi Martin,
> 
> Consider running data-store has below node.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
> /top/interface[name="Ethernet0/0"]/mtu 
> 
> In the above case, "mtu" is a data-store node , because it is part of
> a running data-store ?

Yes.

> And if I just have a path as /top/interface/mtu ==> Here mtu is just a
> "data node" ?

A path by itself can't tell you what kind of node it points to.  If
this is a path into the schema, and mtu is a leaf, then it is a data
node.  If mtu had been a 'choice' it wouldn't be a data node.

> The reason why I am asking these points is that RFC 6536 mentions that
> data-store nodes should not be shown in rpc-error. But we want to
> output in error-message something like "access is denied for
> /top/interface/mtu" to give a meaningful error-message. Whether such
  ^^^^^^^^^^^^^^^^^^

I assume you mean: /top/interface[name="Ethernet0/0"]/mtu ?

> an error-message makes the server non-compliant ?

If the user doesn't have access to "Ethernet0/0" at all, you might
reveal the fact that this interface exists if you send this
error-path.

In general it is safer to just send 'access-denied' and no additional
info.

/martin

> Sent: 05 February 2018 14:20
> > > I had to check, and our implementation matches create-subscription 
> > > if the module-name in the rule is "*".
> > > 
> > > > Q2: If there is an error of access-denied for edit-config 
> > > > operation, does the RFC restrict from outputting the <error-path> 
> > > > of the data-store node for such operations ?

---

From: Rohit R Ranade <[email-masked]>
Date: Mon, 5 Feb 2018 09:24:50 +0000

Hi Martin,

In the above case, "mtu" is a data-store node , because it is part of a running data-store ?

And if I just have a path as /top/interface/mtu ==> Here mtu is just a "data node" ? 

The reason why I am asking these points is that RFC 6536 mentions that data-store nodes should not be shown in rpc-error. But we want to output in error-message something like "access is denied for /top/interface/mtu" to give a meaningful error-message. Whether such an error-message makes the server non-compliant ?

With Regards,
Rohit R

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 05 February 2018 14:20
To: Rohit R Ranade <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Query

Hi,

> what is the difference between this term and "data node". Please 

Is the term "datastore node" really unclear?  Would a defintion "a node in a datastore" help  (I think it would be a tautology).

/martin