[Sis-dtn] FW: [dtn] Clarification on ADU Reassembly

Fri Mar 7 20:28:00 UTC 2025

Sorry, I just realized that it might be helpful to send this to SIS-DTN as well.

Scott

From: sburleig.sb at gmail.com <sburleig.sb at gmail.com> 
Sent: Friday, March 7, 2025 12:22 PM
To: 'Felix Flentge' <Felix.Flentge at esa.int>; dtn at ietf.org
Subject: RE: [dtn] Clarification on ADU Reassembly

Hi, Felix.  Revisiting this lingering issue: I think you are right that a “fragmentation support” extension block is the best solution.  If that extension block contains the bundle processing flags and CRC from the original bundle’s primary block plus a list of all extension blocks in the original bundle, and if it is always required in the offset-zero fragment of the original bundle, then it should be possible to reconstruct the original bundle and validate any BIBs that target the original bundle’s blocks including the primary.  The offset-zero fragment should have all of the extension blocks that were in the original bundle per the list in its fragmentation support extension block (if any are missing then the forwarding of the offset-zero fragment has corrupted it) and the original bundle’s primary block can be recovered from the offset-zero fragment’s primary block and fragmentation support extension block.  I would add that the fragmentation support extension block should also be the target of an additional BIB, applying to the fragment only.

Scott 

From: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> > 
Sent: Wednesday, January 8, 2025 7:09 AM
To: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> ; dtn at ietf.org <mailto:dtn at ietf.org> 
Subject: RE: [dtn] Clarification on ADU Reassembly

Thanks Scott,

So it seems to me that fragmentation is broken (into fragments ... please excuse the bad joke).

The main flaws I see with the current approach are:

1.	We really should have reconstruction of the original bundle (plus / minus some extension blocks). I am not too much concerned about the extension blocks. The ‘required’ extension blocks shall be all present in the ‘zero-offset’ fragment. We may need some way to determine whether extension blocks have been added to the ‘original bundle’ or a fragment (actually this has been my starting point when looking into fragmentation). We can define some block processing control flags for this purpose, eg to determine which extension blocks shall not be processed in a fragment or which ones should be deleted when the ‘original bundle’ is reconstructed. The reconstructed bundle may not have some of the original’s bundle extension blocks or some additional ones but this can happen to any bundle which is transmitted through the network. The point is more to somehow control this behaviour (via block control flags or maybe an fragmentation extension block which may be needed anyway).
2.	Looking at the primary block, the main problem in reconstructing an original bundle seems to be the bundle processing control flags and the CRC type as both could be changed by the fragmenting node. I currently don’t see any other way to maintain this information by adding it to an fragmentation extension block which is then used in the reconstruction of the ‘original bundle’.
3.	Just doing ADU reassembly and constructing a fragment with the complete ADU during bundle delivery seems to be too late and a bit of a hack. In my view, we should have full bundle reconstruction during bundle reception with the reconstructed bundle also undergoing full reception as any other bundle. Otherwise things like reception reporting of the full bundle may fail.

I don’t think that using BIBE is a fully satisfying approach as it will require that all fragments go to the same BIBE endpoint. One reason for having fragmentation at the bundle layer at all has been the argument that a bundle may be too big for a single contact and must be fragmented. The next contact may be with another endpoint, so having the limitation to send all fragments to the same BIBE endpoint introduces a lot of complexity. If we don’t have this use case, I would always push for CLA Layer fragmentation.

I appears to me that improving bundle fragmentation definitely requires some in-depth work, maybe we can find some master thesis or PhD students ... 😉.

Regards,

Felix

From: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com>  <sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> > 
Sent: 07 January 2025 20:32
To: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >; dtn at ietf.org <mailto:dtn at ietf.org> 
Subject: RE: [dtn] Clarification on ADU Reassembly

Hi, Felix.  I think I see your point: section 5.9 describes reassembly of the original ADU, but it doesn’t prescribe reconstruction of the original *bundle* whose payload was that ADU: it doesn’t prescribe reconstruction of that bundle’s primary block, i.e., restoration of the original offset and length, removal of segment offset and original ADU length, restoration of the original CRC, and reinsertion of all applicable extension blocks.

I would say the reason for this is that reconstruction of the original bundle isn’t necessary, because the processing of the fragmentary bundle whose payload was replaced by the reassembled ADU (not the original bundle) proceeds from Step 2 of 5.7; the original bundle’s primary block plays no role in the delivery of the reassembled ADU.

You’re right, the spec says that ADU reassembly may occur at a non-destination node on the path to the destination but it doesn’t provide any details on how this is to be done.  I think nobody thought this was likely enough ever to happen to merit specification, but maybe that’s not true.  We could add some text stating that, in this case, the zero-offset fragment, which now contains the reassembled ADU, should simply be forwarded toward the destination.  The cleanest way to do this, I think, would be for the BPA to “fragment” that bundle, in the usual way, into a new fragment whose fragment offset is zero and whose fragment length is equal to the entire ADU length, and forward that fragment.  (The second “fragment” from this operation is non-existent, as its length would be zero.  We say in 9171 that N must be less than M, but maybe we can relax that constraint under the circumstances.)

Your point on the effect of BPSEC on fragmentation is more concerning.  Any BIBs included in the original bundle, pre-fragmentation, will be carried forward to the destination in the fragment whose fragment offset is zero, so BIBs targeting all blocks other than the primary block should still protect those blocks.  But because the zero-offset fragment necessarily has got a primary block that is different from the primary block of the original bundle, the signature computed for the BIB targeting the primary block (if any) can’t verify.

So maybe this does imply that reconstruction of the original bundle (not just its ADU) really is required in order to support BPSEC.  The problem is that I am not at all confident that we can, in the general case, reconstruct the original bundle upon reassembly of the ADU: as noted in 5.8, replication of all extension blocks in the zero-offset fragment is not necessarily assured.  BIBs targeting extension blocks that didn’t survive fragmentation will still not verify.

I do see one clean solution: as a matter of procedure and configuration (not a protocol mandate), we could agree that a BIB-protected bundle requiring fragmentation should be encapsulated in its entirety – via BIBE – within another bundle, and *that* encapsulating bundle (whose primary block is not BIB-protected) should then be fragmented for forwarding; if the authenticity of those fragments is itself a concern, then the fragments themselves may also be BIBE-encapsulated in individually BIB-protected bundles.  Hey, it’s turtles all the way down.

Scott

From: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> > 
Sent: Tuesday, January 7, 2025 4:45 AM
To: dtn at ietf.org <mailto:dtn at ietf.org> 
Subject: [dtn] Clarification on ADU Reassembly

Hi,

I have been looking into the details of fragmentation and would like to get a clarification regarding Application Data Unit Reassembly:

ADU Reassembly basically works by reconstructing the full ADU from all received fragments and then replacing the payload of the fragment containing offset zero with the full ADU. 

-          Does this imply that a bundle which is fragmented is never or at least not required to be ‘reconstructed’? This seems to contradict the note in RfC 9171, 5.9., that ADU reassembly does enable delivery of the ‘reconstituted original  bundle’? Or is there some implicit ‘reconstitution process’ (e.g., removal of offset and ADU length from Primary Block, eventual CRC re-calculation) expected?

-          What does this mean for in-path ADU reassembly? Is a fragment containing the full ADU or the ‘reconstituted original  bundle’ forwarded? 

-          What does it mean if the primary block has been protected by a BIB before fragmentation occurred? Could this even mean that fragmentation disables any BPSEC? RfC 9172 states ‘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.’  

To me it seems that we should require ‘reconstitution of the original bundle before delivery’ (and eventual security processing) and we may need to add optional ‘bundle reconstitution’ at bundle reception.

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 <mailto:dpo at esa.int> ). 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250307/2f6c40dc/attachment-0001.htm>