Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OSCORE: Added user-defined callback for finding oscore context #1331

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

mopsiok
Copy link

@mopsiok mopsiok commented Feb 21, 2024

Added functionality to restore OSCORE context from external storage (e.g. FLASH), when no context was found by oscore_find_context.

@mopsiok mopsiok force-pushed the feature/add_context_search_callback branch from 1ac0938 to 12629c4 Compare February 21, 2024 12:00
@mrdeep1
Copy link
Collaborator

mrdeep1 commented Feb 21, 2024

Thanks for raising this PR.

I would like to see coap_register_find_context_handler() replaced by coap_register_oscore_context_handler() so that it is obviously a part of OSCORE and not some other generic context function.

I would also like to see man/coap_oscore.txt.in updated to include this new function.

include/coap3/coap_net_internal.h Outdated Show resolved Hide resolved
include/coap3/coap_net_internal.h Outdated Show resolved Hide resolved
src/coap_net.c Outdated Show resolved Hide resolved
@mrdeep1
Copy link
Collaborator

mrdeep1 commented Feb 21, 2024

If you can also change the commit title to

OSCORE: Added user-defined callback for finding oscore context

that would be helpful.

@mopsiok
Copy link
Author

mopsiok commented Feb 22, 2024

Hi,
thank you for your comments! I will get back to this PR in the following week. Currently our team is implementing OSCORE context storage using non-volatile memory. We think our insights could be useful to more people, but we need more time to prepare them for open source consumption.

@mrdeep1
Copy link
Collaborator

mrdeep1 commented Feb 22, 2024

If you are keeping all the oscore_ctx_t outside of libcoap, then I suspect you will need an 'add to external' function as well as the find_context_handler.

A suggested place to do this would be in oscore_enter_context() where it (optionally) gets stored externally and the original one freed off. This function would then need to return the updated (RAM) value for subsequent use.

Then coap_register_oscore_context_handler() can be updated to include the add and find functions.

Edit: A 'remove from external' will be needed as well.

@mopsiok mopsiok force-pushed the feature/add_context_search_callback branch from 12629c4 to 9f2f4ec Compare March 6, 2024 09:32
@mopsiok mopsiok force-pushed the feature/add_context_search_callback branch from 9f2f4ec to 79426d6 Compare March 6, 2024 09:49
@mopsiok mopsiok changed the title Added user-defined callback for finding oscore context OSCORE: Added user-defined callback for finding oscore context Mar 6, 2024
@mopsiok
Copy link
Author

mopsiok commented Mar 6, 2024

Hello again!
I resolved the points you mentioned earlier regarding naming convention and the documentation. The team and I needed to provide some additional changes, which made the NVM context restoring possible. Please take a look when you got some time.

Just to clarify, we didn't want to keep all oscore_ctx_t outside of libcoap - I think it is much better to use existing internal logic to take care of most of the OSCORE work. What we wanted to do, is simply reusing the oscore contexts between device reboots. To achieve it, we decided to use the already available coap_oscore_save_seq_num_t callback, which periodically updates contexts stored in NVM with their respective SSN values. Then, after reboot, we can:

  • (on the client side) manually create proper OSCORE session based on NVM data - completely on the application layer
  • (on the server side) automatically restore the OSCORE session if no matching context is found inside library's RAM, using the callback provided in this PR

This way, the library still works as designed, yet providing additional functionalities in case they are needed. What do you think about such approach?

BTW. I still need to take care of the failing tests, but first, please take a look to make sure you're ok with the general idea.

Copy link
Collaborator

@mrdeep1 mrdeep1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general looking good.

Comment on lines -137 to +142
typedef int (*coap_oscore_save_seq_num_t)(uint64_t sender_seq_num, void *param);
typedef int (*coap_oscore_save_seq_num_t)(uint64_t sender_seq_num,
const coap_bin_const_t *recipient_id,
const coap_bin_const_t *id_context,
void *param);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a change to the Public API which we do not want to have to do unless it is absolutely critical.

My suggestion would be to add in save (and delete) function parameters to coap_register_oscore_context_handler() and call those functions in the appropriate points in the code. Then from a user perspective, everything is in one place for doing the definitions.

Update coap_context-t to include something similar to external_oscore_update_context_handler and external_oscore_delete_context_handler.

Comment on lines +201 to +210
/**
* Opaque pointer for internal oscore_ctx_t type.
*/
typedef struct oscore_ctx_t * oscore_ctx_handle_t;

/**
* Opaque pointer for internal oscore_recipient_ctx_t type.
*
*/
typedef struct oscore_recipient_ctx_t * oscore_recipient_ctx_handle_t;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general for libcoap, all the other typedef struct X X; statements do not have the * (pointer) included. We need to be consistent here.

In general, any forward declarations should be included in the appropriate place in include/coap3/coap_forward_decls.h.

As we are trying to keep the public API to have everything prefixed with coap_ to prevent any name clashes, I think perhaps the 2 forward references (in include/coap3/coap_forward_decls.h) should be

typedef struct oscore_ctx_t coap_oscore_handle_t
typedef struct oscore_recipient_ctx_t coap_oscore_recipient_ctx_handle_t

and then referenced in your changes with the new names.

* @param context The current coap context to use.
* @param handler User callback.
*/
void coap_register_oscore_context_handler(coap_context_t *context, external_oscore_find_context_handler_t handler);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned previously, this should include an add/update handler as well as possibly a delete handler. Even if delete is not currently used, it is a placeholder that will not break the API with that as a change.

@@ -24,6 +24,8 @@
* @{
*/

#include <stdbool.h>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For historical reasons that I cant recall, it was decided that there should not be the use of boolean in the libcoap code, so this should not be used.

*
* @return True if session is encrypted, false if session is not encrypted.
*/
bool coap_session_is_encrypted(const coap_session_t *session);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use int instead of bool, and document return value accordingly.

@@ -26,6 +26,7 @@ coap_session_get_proto,
coap_session_get_state,
coap_session_get_tls,
coap_session_get_type,
coap_session_is_encrypted,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you may have discovered, you will need to add in an entry line into man/Makefile.am

        @echo ".so man3/coap_session.3" > coap_session_get_type.3
+      @echo ".so man3/coap_session.3" > coap_session_is_encrypted.3
        @echo ".so man3/coap_string.3" > coap_delete_bin_const.3

I would also prefer to see this entry at the end of the list, after the set/get functions.

@@ -68,6 +69,8 @@ coap_tls_library_t *tls_lib);*

*coap_session_type_t coap_session_get_type(const coap_session_t *_session_);*

*bool coap_session_is_encrypted(const coap_session_t *session);*
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use int instead of bool.

Comment on lines +261 to +262
*coap_session_is_encrypted*() returns true if the session is using OSCORE encryption, or false if plain CoAP packets are used.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct return types not to be boolean. Also, move this to after the get functions.

Comment on lines +222 to +223
The *coap_session_is_encrypted*() function is used to check if incoming _session_ is encrypted.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be moved to after the get functions.

Comment on lines +406 to +407
rcp_ctx->recipient_id,
osc_ctx->id_context,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately this breaks the public API - See previous comments.

@mrdeep1
Copy link
Collaborator

mrdeep1 commented Mar 6, 2024

we decided to use the already available coap_oscore_save_seq_num_t callback

Unfortunately as mentioned above, this breaks any backwards public API use. See alternative suggestions in my comments. Wherever coap_oscore_save_seq_num_t is called, just call your newly defined add/update handler.

Thanks for doing all this work.

@mrdeep1
Copy link
Collaborator

mrdeep1 commented Apr 26, 2024

@mopsiok Are you able to progress with this PR?

1 similar comment
@mrdeep1
Copy link
Collaborator

mrdeep1 commented May 21, 2024

@mopsiok Are you able to progress with this PR?

@mopsiok
Copy link
Author

mopsiok commented May 21, 2024

Hi,
sorry for the delay. I will need to consult it within my team. I see some of your points, some I would like to discuss first (mainly about the consequences on the application layer which result from current solution) - but I don't have any spare time to continue the topic right now.

For now, feel free to close this PR if you like, and I will contact you when I'm allowed to move this task forward.

Thanks for your time and effort!
Best regards,
Patryk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants