<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;}
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;
mso-ligatures:standardcontextual;}
span.EmailStyle22
{mso-style-type:personal-compose;
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;}
/* List Definitions */
@list l0
{mso-list-id:576717543;
mso-list-type:hybrid;
mso-list-template-ids:1853534286 278013408 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"O%1\.";
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:800534987;
mso-list-type:hybrid;
mso-list-template-ids:-1913069008 2008037108 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-text:"R%1\.";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:966079941;
mso-list-type:hybrid;
mso-list-template-ids:-562933636 78429384 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-text:"S%1\.";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
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">SIS-DTN,<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"> 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:<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">General Observations:<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 lfo1"><span style="font-family:"Calibri",sans-serif">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.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-family:"Calibri",sans-serif">The long-term solution for security and fragmentation cannot be known until we have the long-term solution for fragmentation.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-family:"Calibri",sans-serif">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.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-family:"Calibri",sans-serif">There is a use case for source-fragmentation only that CCSDS feels must be addressed, but:<o:p></o:p></span>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo1"><span style="font-family:"Calibri",sans-serif">The RFC9172 proposal to solve this with bundle-in-bundle encapsulation is seen as “not preferred”.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo1"><span style="font-family:"Calibri",sans-serif">Using CL-level fragmentation is seen as “not preferred”.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo1"><span style="font-family:"Calibri",sans-serif">Having applications build bundles of appropriate size at the source is seen as “not preferred”<o:p></o:p></span></li></ol>
</li></ol>
<p class="MsoListParagraph" style="margin-left:1.0in"><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>
<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">Security Observations:
<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo2"><span style="font-family:"Calibri",sans-serif">All security blocks should include the primary block to bind the security result to a specific bundle (and thus avoid certain attacks).
<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo2"><span style="font-family:"Calibri",sans-serif">A bundle with security involving the primary block cannot be fragmented because the original bundle primary block is never reassembled.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo2"><span style="font-family:"Calibri",sans-serif">A bundle holding a fragment may contain BOTH extension blocks added to that bundle AND extension blocks from the original bundle<o:p></o:p></span>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level2 lfo2"><span style="font-family:"Calibri",sans-serif">And there is no way to tell them apart<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level2 lfo2"><span style="font-family:"Calibri",sans-serif">This can lead to duplicate bundles and errors on applying security blocks to other extension blocks<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level2 lfo2"><span style="font-family:"Calibri",sans-serif">This can lead to errors processing extension blocks and errors securing extension blocks<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level2 lfo2"><span style="font-family:"Calibri",sans-serif">Original bundle extension blocks can never be secured as not being modified from their original bundle form<o:p></o:p></span></li></ol>
</li></ol>
<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>
<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">Orange book recommendations:<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-family:"Calibri",sans-serif">The original bundle being fragmented MUST NOT have any extension blocks in it.<o:p></o:p></span>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level2 lfo3"><span style="font-family:"Calibri",sans-serif">They cannot be secured as having been unchanged from the original bundle into the fragment itself<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level2 lfo3"><span style="font-family:"Calibri",sans-serif">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.<o:p></o:p></span></li></ol>
</li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-family:"Calibri",sans-serif">Each bundle representing a fragment MUST have the “Bundle must not be fragmented” bit set.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-family:"Calibri",sans-serif">A security block MUST NOT involve the primary block unless the “Bundle must not be fragmented” bit has been set in the primary block<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-family:"Calibri",sans-serif">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<o:p></o:p></span>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level2 lfo3"><span style="font-family:"Calibri",sans-serif">Since the original bundle had no extension blocks in it, this should be as expected.<o:p></o:p></span></li></ol>
</li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-family:"Calibri",sans-serif">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.<o:p></o:p></span></li></ol>
<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">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.<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">Thoughts?<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">-Ed<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>Birrane, Edward J. via SIS-DTN<br>
<b>Sent:</b> Friday, March 28, 2025 11:32 AM<br>
<b>To:</b> sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> [EXT] Re: [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> <o:p></o:p></p>
</div>
</div>
<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 <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<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> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><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>
</div>
</body>
</html>