[jira] [Updated] (MYNEWT-751) BLE Host - Policy for SM key overflow

["Christopher Collins (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MYNEWT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher Collins updated MYNEWT-751:
---------------------------------------
    Description: 
The BLE host needs a way to handle the case where a security store write fails because the maximum number of entries have already been written.  Currently, the host simply fails to persist the record and returns an error code.

I propose the following behavior in such a scenario:

# Host checks that there is sufficient storage for a bond before it starts a pairing operation.
# If there is insufficient space, host notifies application of the issue via a callback.
# The callback would return an error code indicating which of the following behaviors to perform:
## Reject the pairing request.
## Proceed with the pairing operation (presumably the application would delete a security entry to make room before returning from the callback).

This raises two issues:
# The pre-check for sufficient storage only works if pairing operations are limited to one at a time.  Perhaps the check could include pairing operations in progress in the count of written entries.
# There isn't an API for the management of persisted security material.  The application would probably need the following functions:
** query the system about which bonds are persisted.
** delete a specified bond from persistence.

  was:
The BLE host needs a way to handle the case where a security store write fails because the maximum number of entries have already been written.  Currently, the host simply fails to persist the record and returns an error code.

I propose the following behavior in such a scenario:

# Host checks that there is sufficient storage for a bond before it starts a pairing operation.
# If there is insufficient space, host notifies application of the issue via the gap event callback. The callback would specify a new event code that specifically indicates security storage exhaustion.
# The gap event callback would return an error code indicating which of the following behaviors to perform:
## Reject the pairing request.
## Proceed with the pairing operation (presumably the application would delete a security entry to make room before returning from the callback).

This raises two issues:
# The pre-check for sufficient storage only works if pairing operations are limited to one at a time.  Perhaps the check could include pairing operations in progress in the count of written entries.
# There isn't an API for the management of persisted security material.  The application would probably need the following functions:
** query the system about which bonds are persisted.
** delete a specified bond from persistence.


> BLE Host - Policy for SM key overflow
> -------------------------------------
>
>                 Key: MYNEWT-751
>                 URL: https://issues.apache.org/jira/browse/MYNEWT-751
>             Project: Mynewt
>          Issue Type: Bug
>          Components: Nimble
>            Reporter: Christopher Collins
>            Assignee: Christopher Collins
>             Fix For: v1_1_0_rel
>
>
> The BLE host needs a way to handle the case where a security store write fails because the maximum number of entries have already been written.  Currently, the host simply fails to persist the record and returns an error code.
> I propose the following behavior in such a scenario:
> # Host checks that there is sufficient storage for a bond before it starts a pairing operation.
> # If there is insufficient space, host notifies application of the issue via a callback.
> # The callback would return an error code indicating which of the following behaviors to perform:
> ## Reject the pairing request.
> ## Proceed with the pairing operation (presumably the application would delete a security entry to make room before returning from the callback).
> This raises two issues:
> # The pre-check for sufficient storage only works if pairing operations are limited to one at a time.  Perhaps the check could include pairing operations in progress in the count of written entries.
> # There isn't an API for the management of persisted security material.  The application would probably need the following functions:
> ** query the system about which bonds are persisted.
> ** delete a specified bond from persistence.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)