libyang icon indicating copy to clipboard operation
libyang copied to clipboard

ly ERR: Invalid identityref "ct:rsa2048" value - identity found in non-implemented module "ietf-crypto-types".(/o-ran-file-management:file-upload/server/keys/algorithm)

Open lorandt1 opened this issue 1 year ago • 8 comments

Using latest devel for both libyang and libnetconf2 I face following errors:

`ly ERR: Invalid identityref "ct:rsa2048" value - identity found in non-implemented module "ietf-crypto-types".(/o-ran-file-management:file-upload/server/keys/algorithm)
nc ERR: Failed to create RPC, perhaps a required feature is disabled.`

When this rpc is being constructed:

<file-upload
	xmlns="urn:o-ran:file-management:1.0">
	<local-logical-file-path>O-RAN/transceiver/sfp_0.sffcap</local-logical-file-path>
	<remote-file-path>sftp://#####################@172.21.0.2/sfp_0.sffcap
		</remote-file-path>
		<password>
			<password>p1</password>
		</password>
		<server>
			<keys>
				<algorithm
					xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">ct:rsa2048
				</algorithm>
				<public-key>AAAAB
						</public-key>
					</keys>
				</server>
			</file-upload> 

Why this error happens ? as it seems that the ietf-crypto-types yang module is implemented:

"nc VBS: Reading module "ietf-crypto-types@2019-04-29" from local file "/ram/yangmodel/ietf-crypto-types.yang".". - it even appears 2 times Also from what comes from server side, conformance type is implement <namespace>urn:ietf:params:xml:ns:yang:ietf-crypto-types</namespace><conformance-type>implement</conformance-type>

All rpc exchange concerning yang modules loading are contained by attached Logs.txt

Yang files for o-ran-file-management and ietf-crypto-types modules are in attached yang.tar.gz

Thank you!

lorandt1 avatar Apr 29 '24 13:04 lorandt1

The fault will most likely be in these errors:

ly ERR: Feature "keystore-supported" not found in module "ietf-keystore".()
nc WRN: Failed to load module "ietf-keystore@2019-04-29".
ly_print_clb(): ly ERR: Feature "local-client-auth-supported" not found in module "ietf-ssh-server".()
lnc2_print_clb(): [172.22.8.2] nc WRN: Failed to load module "ietf-ssh-server@2019-04-29".

And because these modules fail to load, ietf-crypto-types probably fails as well (although I would expect and explicit error for that, too, not sure why there is not). It seems you have not updated your libraries properly, there should be no errors like this. Try to fix this (currently used module revisions are 2023-...) and it should all then work.

michalvasko avatar Apr 30 '24 10:04 michalvasko

Hi @michalvasko, thanks for your reply!

Indeed I don't use the modules provided by libnetconf2 but other ones with different revisions. So I will check with the yang modules using revisions that libnetconf2 provides by default. and see if that solves my issue.

lorandt1 avatar Apr 30 '24 10:04 lorandt1

Could you please let me know what is wrong in ietf-keystore.yang and ietf-ssh-server.yang that leads to those ly ERR yang_2.tar.gz

  • are those valid errors based on RFC ? if yes I would like to fix those.

lorandt1 avatar May 08 '24 13:05 lorandt1

They are really old revisions of the modules, you must use those shipped with libnetconf2.

michalvasko avatar May 09 '24 08:05 michalvasko

Hi,

I have to reopen the issue as I encounter the same issue with other server.. - ly ERR: Invalid identityref "ct:rsa2048" value - identity found in non-implemented module "ietf-crypto-types".(/o-ran-file-management:file-upload/server/keys/algorithm) The initial one was indeed solved with those problematic files

Now the only issues from logs are :

Failed to load module "ietf-netconf-nmda@2019-01-07".
Failed to load module "ietf-netconf-partial-lock@2009-10-19".
Failed to load module "ietf-origin@2018-02-14".
Failed to load module "ietf-yang-patch@2017-02-22".
Failed to load module "yang-data-ext@2017-07-03".
Failed to load module "yumaworks-callhome@2020-10-17".
Failed to load module "yumaworks-config-change@2019-06-09".
Failed to load module "yumaworks-event-stream@2021-05-15".
Failed to load module "yumaworks-lock@2023-04-29".

All logs attached in analysis_2.txt

@michalvasko can you please help to find a solution for this ? I have no control over what will the server report.

lorandt1 avatar May 24 '24 12:05 lorandt1

I do not understand what exactly is happening, all I see in the logs is that again many of them fail to load, not sure why the reason is not printed. I should have asked before, but what libnetconf2 version are you using exactly? It seems like a really old one.

michalvasko avatar May 24 '24 12:05 michalvasko

I am using libnetconf2 v3.0.17. I encounter all these issues during the upgrade from 2.0.24.

Why it looks like an old version is used ? I will try to add debug logs to see what happens.

lorandt1 avatar May 24 '24 12:05 lorandt1

Then perhaps some old files are causing the issues, you can try removing those. Mainly all the modules from (by default) /usr/local/share/yang/modules and then reinstall libnetconf2.

michalvasko avatar May 24 '24 12:05 michalvasko

Hi @michalvasko

It indeed seems to be due to version of ietf-crypto-types.yang as it still appears also without those modules that couldn't be loaded.

I must keep ietf-crypto-types.yang at revision 2019-04-29 because o-ran-file-management.yang @2021-07-26 depends on it.

  • I tried to update only ietf-crypto-types at 2023-12-28 and removerevision-date "2019-04-29"; in o-ran-file-management.yang:
 import ietf-crypto-types {
    prefix "ct";
    revision-date "2019-04-29";
  }

but I got other errrors like ly ERR: The list's key "algorithm" not found.() -> I must use o-ran-file-management.yang at this revision as the server uses this one and If I update to a newer revision where dependency of crypto-types is removed the RPC message will be constructed differently and the server replies with error

The issue can be reproduced if all RPC exchanges from analysis_2.txt are added.

Could you reproduce it and help me find a solution please ? I really need to make the upgrade to latest versions and is long overdue.

lorandt1 avatar May 27 '24 06:05 lorandt1

I must keep ietf-crypto-types.yang at revision 2019-04-29 because o-ran-file-management.yang @2021-07-26 depends on it.

Okay, that makes sense and explains the error, another revision is implemented and so the other one cannot be. If you need both revisions implemented, such a YANG context cannot be created, a limitation of YANG. So I am unable to help, you need to make sure all the module in your context require only a single revision of a module implemented.

michalvasko avatar May 27 '24 06:05 michalvasko

I don't need multiple revisions, only one, which is older than libnetconf2 provides by default for ietf-crypto-types: 2019-04-29.

Could libnetconf2 support that version too and avoid that issue that I face ? If not then I only have 1 option, to add a WA to not have that validation in identityref.c for ct:rsa2048 identityref

lorandt1 avatar May 27 '24 07:05 lorandt1

You need one revision, libnetconf2 needs another = 2 revisions required. And since libnetconf2 requires a newer revision, it is reasonable to update dependencies of O-RAN modules, not libnetconf2.

michalvasko avatar May 27 '24 14:05 michalvasko

thanks for your support, for now I thought to disable the verification for ct:rsa2048 in identityref_check_ident as I can't control the O-RAN modules dependency and neither libnetconf2 to support both revisions.

lorandt1 avatar May 27 '24 14:05 lorandt1