[Sis-dtn] Suggested change to RFC 9172 regarding fragmentation

[Birrane, Edward J.]

SIS-DTN,

  I've given some proposed wording a little more thought, and have the following general observations, security observations, and subsequent recommendations for wording in an orange book:

General Observations:

  1.  Bundle fragmentation as defined in RFC9171 has issues that must be addressed.  I have proposed 2 errata for 9171 and the IETF needs to address this over time.
  2.  The long-term solution for security and fragmentation cannot be known until we have the long-term solution for fragmentation.
  3.  CCSDS needs a short term solution in the form of a BPSec orange book which relaxes a MUST-NOT regarding security and fragmentation present in 9172.
  4.  There is a use case for source-fragmentation only that CCSDS feels must be addressed, but:
     *   The RFC9172 proposal to solve this with bundle-in-bundle encapsulation is seen as "not preferred".
     *   Using CL-level fragmentation is seen as "not preferred".
     *   Having applications build bundles of appropriate size at the source is seen as "not preferred"




Security Observations:

  1.  All security blocks should include the primary block to bind the security result to a specific bundle (and thus avoid certain attacks).
  2.  A bundle with security involving the primary block cannot be fragmented because the original bundle primary block is never reassembled.
  3.  A bundle holding a fragment may contain BOTH extension blocks added to that bundle AND extension blocks from the original bundle
     *   And there is no way to tell them apart
     *   This can lead to duplicate bundles and errors on applying security blocks to other extension blocks
     *   This can lead to errors processing extension blocks and errors securing extension blocks
     *   Original bundle extension blocks can never be secured as not being modified from their original bundle form



Orange book recommendations:

  1.  The original bundle being fragmented MUST NOT have any extension blocks in it.
     *   They cannot be secured as having been unchanged from the original bundle into the fragment itself
     *   This should be a minor issue for source-fragmentation as any extension block that would be added to a large originating bundle could instead be added to the fragments made for that bundle at the source.
  2.  Each bundle representing a fragment MUST have the "Bundle must not be fragmented" bit set.
  3.  A security block MUST NOT involve the primary block unless the "Bundle must not be fragmented" bit has been set in the primary block
  4.  Upon receiving a bundle containing a fragment, ALL security blocks MUST be dispositioned at the bundle destination and all extension blocks removed from the fragment prior to the fragment being used for reassembly
     *   Since the original bundle had no extension blocks in it, this should be as expected.
  5.  Otherwise, adding/removing extension blocks and securing them to any bundle whose "Bundle is a fragment" flag is set should be fine in the network.

The major added change here is that the original bundle should not have extension blocks.  I am trying to find an example where an extension block in the original bundle is needed and cannot think of one because the original bundle is immediately fragmented at the bundle source and the original bundle is actually never sully reassembled so any in-the-network use of any extension block is best applied to fragments anyway.

Thoughts?

-Ed


---
Edward J. Birrane, III, Ph.D.
Chief Engineer, Space Networking
Space Systems Implementation Branch
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839


From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Birrane, Edward J. via SIS-DTN
Sent: Friday, March 28, 2025 11:32 AM
To: sis-dtn at mailman.ccsds.org
Subject: [EXT] Re: [Sis-dtn] Suggested change to RFC 9172 regarding fragmentation

APL external email warning: Verify sender sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org> before clicking links or attachments



I am concerned with this proposed wording:

"Due to the complexities of payload block fragmentation and the effects of fragmentation on the primary block, fragmentation of bundles containing a Bundle Confidentiality Block (BCB) or a Bundle Integrity Block (BIB) MUST NOT occur. This SHALL be enforced by setting the "Bundle must not be fragmented" flag at the bundle's source or at a node fragmentating a bundle before adding any security blocks to the fragments. This flag MUST be set in the primary blocks of all resulting bundles if fragmentation is applied."

This implies that the "original" bundle cannot have any security applied to it. This would drive to implementations where the original bundle would be fragmented and then immediately deleted (unless you want the plaintext and/or unsecured bundle in storage)?

-Ed



---
Edward J. Birrane, III, Ph.D.
Chief Engineer, Space Networking
Space Systems Implementation Branch
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839


From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Lars Baumgaertner via SIS-DTN
Sent: Wednesday, March 26, 2025 11:27 AM
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [EXT] [Sis-dtn] Suggested change to RFC 9172 regarding fragmentation

APL external email warning: Verify sender sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org> before clicking links or attachments



Hi everyone,

Since we keep running into issues with BPSec and fragmentation we would like to suggest a change of Section 5.2 in rfc 9172 (https://www.rfc-editor.org/rfc/rfc9172.html#name-bundle-fragmentation-and-re), to clarify the proper use of BPSec with fragmentation at least a bit.

Before bringing this into the IETF DTN WG, we would like to discuss our proposal here (plus Security WG).

We would like to change the 2nd paragraph in Sec5.2 of the rfc from:
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. Specifically, a BCB or BIB MUST NOT be added to a bundle if the "Bundle is a fragment" flag is set in the bundle processing control flags field.

To:
Due to the complexities of payload block fragmentation and the effects of fragmentation on the primary block, fragmentation of bundles containing a Bundle Confidentiality Block (BCB) or a Bundle Integrity Block (BIB) MUST NOT occur. This SHALL be enforced by setting the "Bundle must not be fragmented" flag at the bundle's source or at a node fragmentating a bundle before adding any security blocks to the fragments. This flag MUST be set in the primary blocks of all resulting bundles if fragmentation is applied.

This would allow fragmentation just once together with security operations either at the source or any relay nodes plus the protection of the fragments but would prevent further fragmentation which could potentially invalidate the BIB, e.g., by targeting the primary block, or a BCB with AAD. Additionally, relay nodes might still add their own security blocks to fragments if needed, e.g., authenticating local QoS blocks for their network segment.

Kind regards,
Lars

--
Lars Baumgaertner
Internal Research Fellow (OPS-GAE)
European Space Agency ESA/ESOC
Robert-Bosch-Str. 5, D-64293 Darmstadt

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<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250408/844221d8/attachment-0001.htm>