prefix not taken into account in key-arg

[robbynet]

Based in Netopeer2 v2.1.36 with following RPC :

<?xml version="1.0"?>
<file-download xmlns="urn:o-ran:file-management:1.0">
  <local-logical-file-path>/tmp/orusim-config.xml</local-logical-file-path>
  <remote-file-path>sftp://[email protected]/tmp/orusim-config-to-send.xml</remote-file-path>
  <password>
    <password>mysftppasswd</password>
  </password>
  <server>
    <keys>
      <algorithm>ct:secp256r1</algorithm>
      <public-key>AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOSC92eVsX3a9Du5sWoku5swcH5XKxZTZ5Vkgcb9Hj5xcB10UM2zLmo313jdWDV3lyOGQML638i3C6bka58V6Xs=</public-key>
    </keys>
  </server>
</file-download>

CLI returns following error message : user-rpc --content /opt/dev/xml/o-ran-file-download-orusim-config-ok.xml ly ERROR: Invalid union value "ct:secp256r1" - no matching subtype found. (Schema location "/o-ran-file-management:file-download/input/credentials/password/server/keys/algorithm", data location "/o-ran-file-management:keys", line number 10.) nc ERROR: Failed to create RPC, perhaps a required feature is disabled. cli_send_recv: Failed to send the RPC.

Yang is defined as follow : container server { list keys { key algorithm; ordered-by user; uses ct:public-key-grouping; description "List of allowed algorithms with its keys"; } description "Key for file server authentication"; }

From RFC 7959, it should be supported, as a key-arg is specified as follow :

• key-arg = node-identifier *(sep node-identifier)
• node-identifier = [prefix ":"] identifier

[michalvasko]

You are mixing things, you have used ct prefix in XML data but not defined its namespace anywhere, so try adding that.

[robbynet]

Ok, got it, so updated xml as follow :

<?xml version="1.0"?>
<file-upload xmlns="urn:o-ran:file-management:1.0" xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
  <local-logical-file-path>/O-RAN/log/trace2.log</local-logical-file-path>
  <remote-file-path>sftp://[email protected]/trace2.log</remote-file-path>
  <password>
    <password>mysftppasswd</password>
  </password>
  <server>
    <keys>
      <ct:algorithm>ct:secp256r1</ct:algorithm>
      <ct:public-key>AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDuX6C0MwNtoHyR5F8PPXSr8XEX4f2k38yQYR22RH/WnodRg2nTiD1hKqEDnhDVxRcDrNGSwfa/LfAyYB4cx11w=</ct:public-key>
    </keys>
  </server>
</file-upload>

I still have error in CLI :

ERROR
        type:     application
        tag:      operation-failed
        severity: error
        message:  Unexpected valid opaque node list "keys".

        type:     application
        tag:      operation-failed
        severity: error
        message:  User callback failed.

With following erro on server side based v2.1.16 : [INF]: LY: Parsing opaque list node "keys" with missing/invalid keys. [INF]: SR: Published event "rpc" "/ietf-netconf:edit-config" with ID 8 priority 0 for 1 subscribers. [INF]: SR: Processing "/ietf-netconf:edit-config" "rpc" event with ID 8 priority 0 (remaining 1 subscribers). [INF]: NP: edit-config error-option "stop-on-error" not supported, rollback-on-error will be performed. [ERR]: LY: Unexpected valid opaque node list "keys". [ERR]: SR: Unexpected valid opaque node list "keys". [ERR]: SR: Applying operation "merge" failed. [INF]: SR: Failed processing of "rpc" event with ID 8 priority 0 (remaining 1 subscribers). [ERR]: SR: Unexpected valid opaque node list "keys". [WRN]: SR: Event "rpc" with ID 8 priority 0 failed (libyang error). [ERR]: SR: User callback failed. [ERR]: NP: Failed to send an RPC (User callback failed). [INF]: NP: Session 7: thread 3 event new RPC. [INF]: NP: Session 7: thread 3 event reply error.

[michalvasko]

The nodes algorithm and public-key belong to the namespace urn:o-ran:file-management:1.0 and not urn:ietf:params:xml:ns:yang:ietf-crypto-types so remove the prefix from those elements, keep it only for the value. When using a grouping, the nodes inherit the namespace of the parent.

[robbynet]

Ok...but doing so CLI reports same error message => Unexpected valid opaque node list "keys" :

<?xml version="1.0"?>
<file-upload xmlns="urn:o-ran:file-management:1.0" xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
  <local-logical-file-path>/O-RAN/log/trace2.log</local-logical-file-path>
  <remote-file-path>sftp://[email protected]/trace2.log</remote-file-path>
  <password>
    <password>mysftppasswd</password>
  </password>
  <server>
    <keys>
      <algorithm>ct:secp256r1</algorithm>
      <public-key>AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDuX6C0MwNtoHyR5F8PPXSr8XEX4f2k38yQYR22RH/WnodRg2nTiD1hKqEDnhDVxRcDrNGSwfa/LfAyYB4cx11w=</public-key>
    </keys>
  </server>
</file-upload>

[michalvasko]

Right... I have actually looked at the type of algorithm and it is an union of number and enumeration. You must not specify prefixes for enumerations, only for identityrefs. So remove the ct: and it should finally work.

[vishalps1]

Hi @michalvasko , I am trying the same thing and facing this issue:

user-rpc --content example/user_rpcs/file-download.xml ly ERROR: Missing the operation node. (Line number 11.) nc ERROR: Failed to create RPC, perhaps a required feature is disabled. cli_send_recv: Failed to send the RPC.

<file-download xmlns="urn:o-ran:file-management:1.0" xmlns="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> <local-logical-file-path>/home</local-logical-file-path> <remote-file-path>sftp://user@ip/home/</remote-file-path> <server> <keys> <algorithm>rsa3072</algorithm> <public-key>AAAAB3NzaC1ycvRm3Tlaszv/6PxS27ReQVryO03ARcUQ3He5X+Wn19kxr09fGCae3Hqh+qH8J4sU+muUc4GlYSgeX1lfd9pusu207CHx28djZSO+QWv0FyPTvfLowpRF6JxXCCGPee2+HxJvC5/24/jObOvqwz4V7ns1LqG=</public-key> </keys> </server> </file-download>

[robbynet]

Thanks for the support !

[michalvasko]

@vishalps1 Your XML is invalid but libyang was not checking for this use-case, seems you are the first one. If you update libyang, you should see the error and hopefully be able to fix it.

[lorandt1]

@michalvasko taking into account that algorithm leaf of type identityref used in o-ran-file-management but imported from ietf-crypto-types defined as follows:

grouping public-key-grouping {
    description
      "A public key.

       The 'algorithm' and 'public-key' nodes are not
       mandatory because they MAY be defined in <operational>.
       Implementations SHOULD assert that these values are
       either configured or that they exist in <operational>.";
    leaf algorithm {
      nacm:default-deny-write;
      type asymmetric-key-algorithm-ref;
      must '../public-key';
      description
        "Identifies the key's algorithm.  More specifically,
         this leaf specifies how the 'public-key' binary leaf
         is encoded.";
      reference
        "RFC CCCC: Common YANG Data Types for Cryptography";
    }

typedef asymmetric-key-algorithm-ref {
    type identityref {
      base asymmetric-key-algorithm;
    }
    description
      "This typedef enables importing modules to easily define an
       identityref to the 'asymmetric-key-algorithm'
       base identity.";
  }

Is following instance with ct:prefix correct: <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">ct:rsa2048</algorithm> ?

[michalvasko]

Yes, identity names (identityref values) should always be fully qualified, must be if they are not from the local module.

[robbynet]

Sorry, I am lost, if syntax with ct:prefix is correct, then why rpc is rejected by Netopeer2-cli ?

[vishalps1]

@vishalps1 Your XML is invalid but libyang was not checking for this use-case, seems you are the first one. If you update libyang, you should see the error and hopefully be able to fix it.

Hi @michalvasko, I didn't get how my XML is invalid. I was not able to paste the XML properly, but the XML is working for me but I am getting the above specified error. Pasting XML screenshot here for reference:

Error on Netconf-Cli

[chendrashekarp]

Hi @michalvasko , facing same issue, could you please help me with this.

[michalvasko]

@robbynet The algorithm node @lorandt1 mentioned is of type asymmetric-key-algorithm-ref which is an identityref. Your algorithm node was a union with enumeration. Hence the difference.

@chendrashekarp Just read the issue and you should know the solution.

[lorandt1]

Hi, @michalvasko I will attach the used yang files to make it clear. As you confirmed earlier

Yes, identity names (identityref values) should always be fully qualified, must be if they are not from the local module.

the following rpc is correct.

 <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="71">
    <file-upload xmlns="urn:o-ran:file-management:1.0">
	<local-logical-file-path>/O-RAN/log/troubleshooting1-2022-08-25_13-06-58.log</local-logical-file-path>
	<remote-file-path>sftp://[email protected]/troubleshooting1-2022-08-25_13-06-58.log</remote-file-path>
	    <password>
	        <password>V7_QOcf8Y6wX5v55312290448552</password>
		</password>
		<server>
		    <keys>
			    <algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">ct:rsa2048</algorithm>
				<public-key>lWtQ5hz3gc5XNQ/Vbk4ny6joGM3xMwxtv+rcC9cIk</public-key>
		    </keys>
	    </server>
	</file-upload>
</rpc>

Then why with Netopeer2 v2.1.36 following error is returned ?

<rpc-error><error-type>application</error-type><error-tag>operation-failed</error-tag><error-severity>error</error-severity><error-message xml:lang="en">RPC input validation failed.</error-message></rpc-error>

Can we say it is a netopeer2 bug ?

yangModulesDefinition.zip

[michalvasko]

The RPC looks fine, what is the full error netopeer2 produces?

[lorandt1]

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="71"> <rpc-error> <error-type>application</error-type> <error-tag>operation-failed</error-tag> <error-severity>error</error-severity>\ <error-message xml:lang="en">Unexpected valid opaque node list "keys".</error-message> </rpc-error> <rpc-error> <error-type>application</error-type> <error-tag>operation-failed</error-tag> <error-severity>error</error-severity> <error-message xml:lang="en">RPC input validation failed.</error-message> </rpc-error> </rpc-reply>

[michalvasko]

In my case the problem was that while you are using ietf-crypto-types@2019-04-29, netopeer2 installs ietf-crypto-types@2019-07-02 replacing the older revision and the identityref with an enumeration causing this value to be, again, invalid.

[lorandt1]

@michalvasko thank you so much!