<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:0cm;
font-size:11.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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-GB" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi everyone,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Before bringing this into the IETF DTN WG, we would like to discuss our proposal here (plus Security WG).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We would like to change the 2<sup>nd</sup> paragraph in Sec5.2 of the rfc from:<o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To:<o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kind regards,<o:p></o:p></p>
<p class="MsoNormal">Lars<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-GB">-- <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-GB">Lars Baumgaertner<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-GB">Internal Research Fellow (OPS-GAE)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-GB">European Space Agency ESA/ESOC<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-GB">Robert-Bosch-Str. 5, D-64293 Darmstadt</span><span style="mso-fareast-language:EN-GB"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
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@esa.int).
</body>
</html>