<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Aptos",serif;
mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Aptos",serif;
mso-ligatures:standardcontextual;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:234630538;
mso-list-type:hybrid;
mso-list-template-ids:437959226 134807567 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1447503565;
mso-list-type:hybrid;
mso-list-template-ids:601236654 -1393253236 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Aptos",serif;
mso-fareast-font-family:Aptos;
mso-bidi-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2
{mso-list-id:2030989513;
mso-list-template-ids:639002662;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#467886" vlink="#96607D" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='font-family:"Calibri",sans-serif'>Sorry, I just realized that it might be helpful to send this to SIS-DTN as well.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif'>Scott<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-family:"Calibri",sans-serif;mso-ligatures:none'>From:</span></b><span style='font-family:"Calibri",sans-serif;mso-ligatures:none'> sburleig.sb@gmail.com <sburleig.sb@gmail.com> <br><b>Sent:</b> Friday, March 7, 2025 12:22 PM<br><b>To:</b> 'Felix Flentge' <Felix.Flentge@esa.int>; dtn@ietf.org<br><b>Subject:</b> RE: [dtn] Clarification on ADU Reassembly<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif'>Scott <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-family:"Calibri",sans-serif;mso-ligatures:none'>From:</span></b><span style='font-family:"Calibri",sans-serif;mso-ligatures:none'> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>> <br><b>Sent:</b> Wednesday, January 8, 2025 7:09 AM<br><b>To:</b> <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; <a href="mailto:dtn@ietf.org">dtn@ietf.org</a><br><b>Subject:</b> RE: [dtn] Clarification on ADU Reassembly<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB>Thanks Scott,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>So it seems to me that fragmentation is broken (into fragments ... please excuse the bad joke).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>The main flaws I see with the current approach are:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><ol style='margin-top:0in' start=1 type=1><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo3'><span lang=EN-GB>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).<o:p></o:p></span></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo3'><span lang=EN-GB>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’.<o:p></o:p></span></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo3'><span lang=EN-GB>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.<o:p></o:p></span></li></ol><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>I appears to me that improving bundle fragmentation definitely requires some in-depth work, maybe we can find some master thesis or PhD students ... </span><span lang=EN-GB style='font-family:"Segoe UI Emoji",sans-serif'>😉</span><span lang=EN-GB>.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-GB style='mso-ligatures:none'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-ligatures:none'>Felix<o:p></o:p></span></p></div><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><b><span style='font-family:"Calibri",sans-serif;mso-ligatures:none'>From:</span></b><span style='font-family:"Calibri",sans-serif;mso-ligatures:none'> <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>> <br><b>Sent:</b> 07 January 2025 20:32<br><b>To:</b> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>; <a href="mailto:dtn@ietf.org">dtn@ietf.org</a><br><b>Subject:</b> RE: [dtn] Clarification on ADU Reassembly<o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'>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 *<b>bundle</b>* 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.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'>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 (<b><u>not</u></b> 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.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'>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.)<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'>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.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'>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.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'>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 *<b>that</b>* 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.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'>Scott<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><b><span style='font-family:"Calibri",sans-serif;mso-ligatures:none'>From:</span></b><span style='font-family:"Calibri",sans-serif;mso-ligatures:none'> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>> <br><b>Sent:</b> Tuesday, January 7, 2025 4:45 AM<br><b>To:</b> <a href="mailto:dtn@ietf.org">dtn@ietf.org</a><br><b>Subject:</b> [dtn] Clarification on ADU Reassembly<o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB>Hi,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB>I have been looking into the details of fragmentation and would like to get a clarification regarding Application Data Unit Reassembly:<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB>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. <o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo5'><![if !supportLists]><span lang=EN-GB><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>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?<o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo5'><![if !supportLists]><span lang=EN-GB><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>What does this mean for in-path ADU reassembly? Is a fragment containing the full ADU or the ‘reconstituted original bundle’ forwarded? <o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo5'><![if !supportLists]><span lang=EN-GB><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>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.’ <o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB>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.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB style='mso-ligatures:none'>Regards,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB style='mso-ligatures:none'>Felix<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB style='font-size:12.0pt;mso-ligatures:none'>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 (<a href="mailto:dpo@esa.int">dpo@esa.int</a>). <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:12.0pt;font-family:"Times New Roman",serif;mso-ligatures:none'>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 (<a href="mailto:dpo@esa.int">dpo@esa.int</a>). <o:p></o:p></span></p></div></body></html>