<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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:Aptos;
mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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">I am concerned with this proposed wording:<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 lang="EN-GB">“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.”<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">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)?<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">-Ed<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><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"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;mso-ligatures:none">---<br>
Edward J. Birrane, III, Ph.D. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;mso-ligatures:none">Chief Engineer, Space Networking<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;mso-ligatures:none">Space Systems Implementation Branch<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;mso-ligatures:none">Space Exploration Sector<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;mso-ligatures:none">Johns Hopkins Applied Physics Laboratory<br>
(W) 443-778-7423 / (F) 443-228-3839<br>
</span><span style="font-family:"Calibri",sans-serif;mso-ligatures:none"> <o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<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"> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Lars Baumgaertner via SIS-DTN<br>
<b>Sent:</b> Wednesday, March 26, 2025 11:27 AM<br>
<b>To:</b> sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> [EXT] [Sis-dtn] Suggested change to RFC 9172 regarding fragmentation<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div id="APLWarningText">
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" align="left">
<tbody>
<tr>
<td width="100%" style="width:100.0%;background:#E0E0E0;padding:0in 0in 0in 0in">
<p class="MsoNormal" style="mso-element:frame;mso-element-frame-hspace:2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly">
<b><span style="font-family:"Calibri",sans-serif;color:red;mso-ligatures:none">APL external email warning:
</span></b><span style="font-family:"Calibri",sans-serif;color:black;mso-ligatures:none">Verify sender
<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a> before clicking links or attachments</span><span style="font-family:"Calibri",sans-serif;mso-ligatures:none"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p><span lang="EN-GB"> <o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB">Hi everyone,<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">Since we keep running into issues with BPSec and fragmentation we would like to suggest a change of Section 5.2 in rfc 9172 (<a href="https://www.rfc-editor.org/rfc/rfc9172.html#name-bundle-fragmentation-and-re">https://www.rfc-editor.org/rfc/rfc9172.html#name-bundle-fragmentation-and-re</a>),
to clarify the proper use of BPSec with fragmentation at least a bit.<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">Before bringing this into the IETF DTN WG, we would like to discuss our proposal here (plus Security WG).<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">We would like to change the 2<sup>nd</sup> paragraph in Sec5.2 of the rfc from:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">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.<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">To:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">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.<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">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.<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">Kind regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Lars<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" style="mso-fareast-language:EN-GB">-- <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-GB">Lars Baumgaertner<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-GB">Internal Research Fellow (OPS-GAE)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-GB">European Space Agency ESA/ESOC<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-GB">Robert-Bosch-Str. 5, D-64293 Darmstadt<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" style="font-family:"Calibri",sans-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>
</div>
</body>
</html>