[Sis-dtn] Fragmentation and Extension Blocks

[Felix Flentge]

Dear All,

Thanks for the good discussion on BP fragmentation last week. While I think that BP fragmentation should be improved and we may need 'full bundle reassembly' instead of 'ADU reassembly' at some time, we should also try to find a pragmatic solution for the next years asap (LunaNet needs this *now*). We have had some internal discussions which lead to the following conclusions and suggestions. It's a bit tricky and we would welcome additional analysis.


  1.  The 'good news': Previous Node / Bundle Age / Hop Count Extension Blocks:
We don't see a particular, fragmentation-related issue with those; they should be fine whether added or processed in unfragmented or fragmented bundles (TBC, certainly something to test in interop testing)

--> No changes to CCSDS BPv7 Book are required

  2.  The 'easy solution': Custody Transfer Extension Blocks (CTEB) and Compressed Reporting Extension Blocks (CREB)
Here we are in control as we are writing the specification. I would probably just add a requirements:

CTEB or CREB can only be added to a bundle if the 'Bundle must not be fragmented' flag is set to true.

NOTE: This does allow for proactive source fragmentation of an ADU before the bundle is forwarded provided that the 'Bundle must not be fragmented' flag is set in the resulting fragments. It does also allow for adding CREB/CTEB while the bundle is being forwarded by intermediate nodes provided that the flag is set. Even if the flag is not set for a unfragmented bundle, these blocks could be added if this bundle is fragmented before forwarding (in the extreme case, there could be just a single fragment).


--> Will simply be addressed in the Custody Transfer & Compressed Status Reporting Orange Book


  1.  The 'basically ok part': BPSEC BCB

The main rules in RfC 9172:
a) 'Due to the complexity of payload-block fragmentation, including the possibility of fragmenting payload-block fragments, integrity and confidentiality operations are not to be applied to a bundle representing a fragment.'
(I am a bit wondering why this is not SHALL / MUST - maybe should be improved in an updated RfC)

b) 'A node should apply any confidentiality protection prior to performing any fragmentation.'
(Again, why not in normative language - maybe should be improved in an updated RfC)
c) 'BCBs MUST have the "Block must be replicated in every fragment" flag set if one of the targets is the payload block.  Having that BCB in each fragment indicates to a receiving node that the payload portion of each fragment represents ciphertext.'
(I don't understand the reason for this - maybe somebody can explain to me or the requirement should be dropped)

So, if we add a BCB targeting a payload block to an unfragmented bundle, everything should be fine and we could decrypt after ADU re-assembly. However, we may consider adding more normative language to the BPSEC book (ideally, the point above would be addressed in RfC 9172), eg:

1) BCB extension blocks shall only be added to unfragmented bundles.

--> Could be added to CCSDS BPSEC Book



  1.  The 'difficult part': BPSEC BIB



The main rules in RfC 9172:
a) 'Due to the complexity of payload-block fragmentation, including the possibility of fragmenting payload-block fragments, integrity and confidentiality operations are not to be applied to a bundle representing a fragment.'
(I am a bit wondering why this is not SHALL / MUST - maybe should be improved in an updated RfC)

b)  'Security processing in the presence of payload-block fragmentation may be handled by other mechanisms outside of the BPSec protocol or

   by applying BPSec blocks in coordination with an encapsulation mechanism.'

This is problematic as it
-             makes BIB protection of the primary block difficult in the case the bundle gets fragmented; In RfC 9171, the primary block is never re-constructed; this may be currently possible but is not described; depending on future bundle processing control flag, it might become even more difficult and may require guesses about original values of these flags.

  *   it does not allow to protect the primary header of fragments which is extremely useful in the case of proactive source fragmentation



Therefore, I would suggest the following rules:
1. BIB shall only be added to bundles which have the 'Bundle must not be fragmented' flag set to true.

(This is stricter then RfC 9172 requires but this should be fine in a tailoring; it would be even better to add this requirement to RfC 9172 or explain how integrity protection of primary blocks should work in case the bundle got fragmented)


2. "BIB" may be added to fragments if the 'Bundle must not be fragmented' flag set to true.


Obviously, this is in contradiction to a) above. So, either this needs to be changed in the RfC 9172 or we take the escape offered by b). This would mean defining a 'CCSDS Fragment BIB' which looks the same as the BPSEC BIB but has a different block type code. This should be doable but is clearly the non-preferred solution.



  *   We should address it with IETF. If we cannot find a solution (in time) we might need to do the 'CCSDS Fragment BIB' and address it in the CCSDS BPSEC specification.

One last remark: yes, these issues can also (partially) be addressed with encapsulation which is completely fine. However, we should be able to do eg integrity protection without the need of encapsulation. To require encapsulation feels to me like a workaround because we did not manage to address the issues adequately in the standards. Furthermore, my main problem with encapsulation is that the currently proposed mechanisms require the explicit knowledge of the endpoint ID of the hop de-encapsulating the bundle which might be difficult to know at the time of forwarding.

Regards,
Felix

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250123/2200b213/attachment-0001.htm>