Subject: [Netconf] NACM edit-config clarification

From: "Szekely, Szabolcs (Nokia - HU/Budapest)" <[email-masked]>
Date: Tue, 27 Jun 2017 15:49:03 +0000

Hi,

There is this part in the NACM RFC section 3.2.3 https://tools.ietf.org/html/rfc6536#section-3.2.3:
   A "merge" or "replace" <edit-config> operation may include data nodes
   that do not alter portions of the existing datastore.  For example, a
   container or list node may be present for naming purposes but does
   not actually alter the corresponding datastore node.  These unaltered
   data nodes are ignored by the server and do not require any access
   rights by the client.

   A "merge" <edit-config> operation may include data nodes but not
   include particular child data nodes that are present in the
   datastore.  These missing data nodes within the scope of a "merge"
   <edit-config> operation are ignored by the server and do not require
   any access rights by the client.

This means that if I have rules that allow the creation of a list element, but denies the update of the list element leafs, then I can send the same edit-config as many times as I want, because after the first time (create is allowed) the edit-config will not alter the datastore?

Example yang, nacm rule and edit-config snippets:

container test-container {
    list test-list {
        key parameter-1;
        leaf parameter-1 {
            type string;
        }
        leaf parameter-2 {
            type string;
        }
    }
}

      <rule>
        <name>update-deny</name>
        <module-name>test-module</module-name>
        <path>/test-container/test-list/*</path>
        <access-operations>update delete read</access-operations>
        <action>deny</action>
      </rule>
      <rule>
        <name>create-allow</name>
        <module-name>test-module</module-name>
        <path>/test-container</path>
        <access-operations>create read</access-operations>
        <action>allow</action>
      </rule>

<rpc message-id="rpc-1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>merge</default-operation>
    <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <test-container xmlns="http://test.com">
            <test-list>
                <parameter-1>key-1</parameter-1>
                <parameter-2>parameter-2</parameter-2>
            </test-list>
        </test-container>
    </config>
  </edit-config>
</rpc>

Thanks for your help,
Szabolcs Szekely

Szabolcs Székely
Nokia

---

From: "Xiang Li" <[email-masked]>
Date: Tue, 27 Jun 2017 15:12:03 -0500

Hi,
 
Technically speaking, the <edit-config> with “merge” operation in your
example would not result in the *modification* of a datastore node since the
value supplied is the same as the value currently held by the server so
arguably  you may be able to send the same edit-config as many times as you
want without getting an <access-denied> error.
 
However according to RFC7950 YANG 1.1.

 <https://tools.ietf.org/html/rfc7950#section-7.6.7> 7.6.7.  NETCONF
<edit-config> Operations

   When a NETCONF server processes an <edit-config> request, the

   elements of procedure for the leaf node are as follows:

   o  If the operation is "merge" or "replace", the node is created if

      it does not exist, and its value is set to the value found in the

      XML RPC data.

Clearly, the node already exists after the initial <edit-config>, so a
*compliant* server implementation will determine that the instance node is
already there and all it needs to do is to set to the value found in your
subsequent <edit-config>. But to do that, it needs “update” rights, and
hence the server must send back an “access-denied” error.
 
In other words, there is no requirement a server implementation must check
if the new value in an <edit-config> is different than the value already in
the server. 
 
And I think it also makes sense to reject the rest <edit-conig> in your
examples when your NACM is in effect.
 
-Xiang

From: Netconf [mailto:[email-masked]] On Behalf Of Szekely,
Szabolcs (Nokia - HU/Budapest)
Sent: Tuesday, June 27, 2017 10:49 AM
To: [email-masked]
Subject: [Netconf] NACM edit-config clarification

Hi,

There is this part in the NACM RFC section 3.2.3
<https://tools.ietf.org/html/rfc6536#section-3.2.3>
https://tools.ietf.org/html/rfc6536#section-3.2.3:

   rights by the client.

This means that if I have rules that allow the creation of a list element,
but denies the update of the list element leafs, then I can send the same
edit-config as many times as I want, because after the first time (create is
allowed) the edit-config will not alter the datastore?

    list test-list {

        key parameter-1;

        leaf parameter-1 {

            type string;

        }

        leaf parameter-2 {

            type string;

        }

    }

}

      <rule>

        <name>update-deny</name>

        <action>deny</action>

      </rule>

      <rule>

        <action>allow</action>

      </rule>

  <edit-config>

    <target>

      <candidate/>

    </target>

            <test-list>

            </test-list>

        </test-container>

    </config>

  </edit-config>

</rpc>

Thanks for your help,

Szabolcs Szekely

Szabolcs Székely

Nokia

---

From: "Szekely, Szabolcs (Nokia - HU/Budapest)" <[email-masked]>
Date: Wed, 28 Jun 2017 13:18:47 +0000

Hi,

Sorry I didn't mention that I am using YANG 1.0.

I suppose in cases like this the YANG 1.1 RFC can act as a guideline or what the authors intended with the previous YANG version.

Thanks for the help,
Szabolcs

Szabolcs Székely
Nokia

From: Xiang Li [mailto:[email-masked]]
Sent: Tuesday, June 27, 2017 10:12 PM
To: Szekely, Szabolcs (Nokia - HU/Budapest) <[email-masked]>; [email-masked]
Subject: RE: [Netconf] NACM edit-config clarification

Hi,

Technically speaking, the <edit-config> with "merge" operation in your example would not result in the *modification* of a datastore node since the value supplied is the same as the value currently held by the server so arguably  you may be able to send the same edit-config as many times as you want without getting an <access-denied> error.

However according to RFC7950 YANG 1.1.
7.6.7<https://tools.ietf.org/html/rfc7950#section-7.6.7>.  NETCONF <edit-config> Operations

Clearly, the node already exists after the initial <edit-config>, so a *compliant* server implementation will determine that the instance node is already there and all it needs to do is to set to the value found in your subsequent <edit-config>. But to do that, it needs "update" rights, and hence the server must send back an "access-denied" error.

In other words, there is no requirement a server implementation must check if the new value in an <edit-config> is different than the value already in the server.

And I think it also makes sense to reject the rest <edit-conig> in your examples when your NACM is in effect.

-Xiang

From: Netconf [mailto:[email-masked]] On Behalf Of Szekely, Szabolcs (Nokia - HU/Budapest)
Sent: Tuesday, June 27, 2017 10:49 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Netconf] NACM edit-config clarification

Hi,

      <rule>
        <name>update-deny</name>

Thanks for your help,
Szabolcs Szekely

Szabolcs Székely
Nokia

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Jun 2017 14:37:06 +0200 (CEST)

Hi,

"Xiang Li" <[email-masked]> wrote:
> Hi,
>  
> Technically speaking, the <edit-config> with merge operation in your
> subsequent <edit-config>. But to do that, it needs update rights, and
> hence the server must send back an access-denied error.

This is not what RFC 6536 says.  RFC 6536 says:

   A "merge" or "replace" <edit-config> operation may include data nodes
   that do not alter portions of the existing datastore.
   [...]
   These unaltered data nodes are ignored by the server and do not
   require any access rights by the client.

Setting a leaf to the same value as it already has does not alter the
existing datastore, so this is allowed.

However, this means that a client that doesn't even have read access
to a node can try to guess the value and send an edit-config with the
guessed value.  If it gets back ok it means the guessed value is in
fact the value set in the config.  So maybe it makes sense to require
*read* access to these unaltered nodes.

In any case, I think we should clarify the behavior in 6536bis.

/martin