Subject: [dtn] BPSec handling of target CRC

From: Brian Sipos <[email-masked]>
Date: Wed, 23 Dec 2020 04:39:24 +0000

Ed,
The current BPSec draft [1] seems to be silent about what a security source is supposed to do with BIB-target block CRC Type and CRC Value fields. It's clear that adding a BIB targeting a block will affect the block-type-specific data, but not clear whether there is an obligation to also update (or remove) CRC fields while adding BIB blocks.
Likewise, I don't see any obligation of the security acceptor to do anything to "put back" any CRC fields.

Slightly related, Section 9.3 "Authorship" does recommend that security contexts take into account target block CRC fields as additional authenticated data (AAD). This is not terrible, but it adds fragility and potential interoperability problems.
The contexts in [2], correctly I think, ignore CRC type and value of target blocks for generating IPPT and AAD data.

A BIB and a BCB which both target the same block (the BIB to provide data origination, and the BCB to provide encryption) could collide if the BCB processing does not "put back" the original CRC fields. But then what if the original CRC value was invalid?
It seems like a prohibition on security sources doing anything on a target block with an invalid CRC value, or an explicit requirement that security contexts leave-out CRC value as AAD, is needed.
Although the BCB-and-BIB with the same target is prohibited when only data integrity is desired, this use case is to provide data origination bound to a security source's public key / certificate.

My own feeling on this is that security sources should preserve the CRC Type (as the block originator set it for a reason) and update the CRC Value for the new block data, and security acceptors should update the CRC Value when processing a BIB target.

[1] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-25
[2] https://tools.ietf.org/html/draft-ietf-dtn-bpsec-interop-sc-02