<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: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:Aptos;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* 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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:11.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;
mso-fareast-language:EN-US;}
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;}
/* List Definitions */
@list l0
{mso-list-id:553545141;
mso-list-type:hybrid;
mso-list-template-ids:-924399336 134807569 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@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:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@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:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@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:1395271360;
mso-list-type:hybrid;
mso-list-template-ids:-823341136 166519270 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l1:level1
{mso-level-start-at:2;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:54.0pt;
text-indent:-18.0pt;
font-family:"Aptos",sans-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;
margin-left:90.0pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:126.0pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:162.0pt;
text-indent:-18.0pt;
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;
margin-left:198.0pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:234.0pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:270.0pt;
text-indent:-18.0pt;
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;
margin-left:306.0pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:342.0pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2
{mso-list-id:1753160550;
mso-list-type:hybrid;
mso-list-template-ids:-564624118 -2116652010 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l2:level1
{mso-level-start-at:2;
mso-level-number-format:bullet;
mso-level-text:\F0E8;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:54.0pt;
text-indent:-18.0pt;
font-family:Wingdings;
mso-fareast-font-family:Aptos;
mso-bidi-font-family:"Times New Roman";}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:90.0pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:126.0pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:162.0pt;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:198.0pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:234.0pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:270.0pt;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:306.0pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:342.0pt;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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">Dear All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for the good discussion on BP fragmentation last week. While I think that BP fragmentation should be improved and we may need ‘full bundle reassembly’ instead of ‘ADU reassembly’ at some time, we should also try to find a pragmatic
solution for the next years asap (LunaNet needs this *now*). We have had some internal discussions which lead to the following conclusions and suggestions. It’s a bit tricky and we would welcome additional analysis.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">The ‘good news’: Previous Node / Bundle Age / Hop Count Extension Blocks:<br>
We don’t see a particular, fragmentation-related issue with those; they should be fine whether added or processed in unfragmented or fragmented bundles (TBC, certainly something to test in interop testing)<br>
<br>
<span style="font-family:Wingdings">à</span> No changes to CCSDS BPv7 Book are required<br>
<br>
<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">The ‘easy solution’: Custody Transfer Extension Blocks (CTEB) and Compressed Reporting Extension Blocks (CREB)<br>
Here we are in control as we are writing the specification. I would probably just add a requirements:<br>
<br>
CTEB or CREB can only be added to a bundle if the ‘Bundle must not be fragmented’ flag is set to true.<br>
<br>
NOTE: This does allow for proactive source fragmentation of an ADU before the bundle is forwarded provided that the ‘Bundle must not be fragmented’ flag is set in the resulting fragments. It does also allow for adding CREB/CTEB while the bundle is being forwarded
by intermediate nodes provided that the flag is set. Even if the flag is not set for a unfragmented bundle, these blocks could be added if this bundle is fragmented before forwarding (in the extreme case, there could be just a single fragment).<br>
<br>
<o:p></o:p></li></ol>
<p class="MsoListParagraph"><span style="font-family:Wingdings">à</span> Will simply be addressed in the Custody Transfer & Compressed Status Reporting Orange Book<br>
<br>
<o:p></o:p></p>
<ol style="margin-top:0cm" start="3" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">The ‘basically ok part’: BPSEC BCB<br>
<br>
The main rules in RfC 9172:<br>
a) ‘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.’<br>
(I am a bit wondering why this is not SHALL / MUST – maybe should be improved in an updated RfC)<o:p></o:p></li></ol>
<p class="MsoListParagraph">b) ‘A node should apply any confidentiality protection prior to performing any fragmentation.’<br>
(Again, why not in normative language – maybe should be improved in an updated RfC)<br>
c) ‘BCBs MUST have the "Block must be replicated in every fragment" flag set if one of the targets is the payload block. Having that BCB in each fragment indicates to a receiving node that the payload portion of each fragment represents ciphertext.’<br>
(I don’t understand the reason for this – maybe somebody can explain to me or the requirement should be dropped)<br>
<br>
So, if we add a BCB targeting a payload block to an unfragmented bundle, everything should be fine and we could decrypt after ADU re-assembly. However, we may consider adding more normative language to the BPSEC book (ideally, the point above would be addressed
in RfC 9172), eg:<br>
<br>
1) BCB extension blocks shall only be added to unfragmented bundles.<br>
<br>
<span style="font-family:Wingdings">à</span> Could be added to CCSDS BPSEC Book<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0cm" start="4" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">The ‘difficult part’: BPSEC BIB<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">The main rules in RfC 9172:<br>
a) ‘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.’<br>
(I am a bit wondering why this is not SHALL / MUST – maybe should be improved in an updated RfC)<o:p></o:p></p>
<p class="MsoListParagraph">b) ‘Security processing in the presence of payload-block fragmentation may be handled by other mechanisms outside of the BPSec protocol or<o:p></o:p></p>
<p class="MsoListParagraph"> by applying BPSec blocks in coordination with an encapsulation mechanism.’<br>
<br>
This is problematic as it <br>
- makes BIB protection of the primary block difficult in the case the bundle gets fragmented; In RfC 9171, the primary block is never re-constructed; this may be currently possible but is not described; depending on future bundle processing control
flag, it might become even more difficult and may require guesses about original values of these flags.<o:p></o:p></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph" style="margin-left:18.0pt;mso-list:l1 level1 lfo2">it does not allow to protect the primary header of fragments which is extremely useful in the case of proactive source fragmentation<o:p></o:p></li></ul>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">Therefore, I would suggest the following rules:<br>
1. BIB shall only be added to bundles which have the ‘Bundle must not be fragmented’ flag set to true.<br>
<br>
(This is stricter then RfC 9172 requires but this should be fine in a tailoring; it would be even better to add this requirement to RfC 9172 or explain how integrity protection of primary blocks should work in case the bundle got fragmented)<br>
<br>
<o:p></o:p></p>
<p class="MsoListParagraph">2. “BIB” may be added to fragments if the ‘Bundle must not be fragmented’ flag set to true.<br>
<br>
<o:p></o:p></p>
<p class="MsoListParagraph">Obviously, this is in contradiction to a) above. So, either this needs to be changed in the RfC 9172 or we take the escape offered by b). This would mean defining a ‘CCSDS Fragment BIB’ which looks the same as the BPSEC BIB but has
a different block type code. This should be doable but is clearly the non-preferred solution.<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph" style="margin-left:18.0pt;mso-list:l2 level1 lfo3">We should address it with IETF. If we cannot find a solution (in time) we might need to do the ‘CCSDS Fragment BIB’ and address it in the CCSDS BPSEC specification.<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One last remark: yes, these issues can also (partially) be addressed with encapsulation which is completely fine. However, we should be able to do eg integrity protection without the need of encapsulation. To require encapsulation feels
to me like a workaround because we did not manage to address the issues adequately in the standards. Furthermore, my main problem with encapsulation is that the currently proposed mechanisms require the explicit knowledge of the endpoint ID of the hop de-encapsulating
the bundle which might be difficult to know at the time of forwarding.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="mso-ligatures:none;mso-fareast-language:EN-GB">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-ligatures:none;mso-fareast-language:EN-GB">Felix<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>