BrianSipos
commented
11 months ago One way to deal with this kind of thing is to not include any parameter or result handling in the ASB and instead defer all context-id-specific handling to a class hierarchy registered for individual Context ID values. This would be similar to how block-type-specific data handling is deferred to block-type handling classes.
rdudukov
The current decoding behavior in
Bpv7AbstractSecurityBlock::DeserializeIdValuePairBpv7()requires that the implementation have type-specific handling for all possible security context IDs, which is an incredibly difficult ask of HDTN. Even if #51 is implemented, there are still situations where the BPA needs to know that a BCB is targeting specific blocks even if the BCB has a security context which itself cannot be handled.For example, the proposed BPSec COSE context uses a CBOR map for the AAD Scope parameter.
Unfortunately, the handling of generic ASB parameter or result values requires a recursive CBOR decoder. Such a decoder is available from QCBOR or others on the cbor.io listing, but this would add a build dependency to HDTN.
Since the parameters and results are at the end of the BTSD, it would also be possible for the HDTN decoder to have an indication on the ASB that it was able to decode up to the parameters successfully, but not parameters or results. This would allow BPSec processing to be able to use the target list and context ID without needing to actually use any of the parameters or results.