[Sis-dtn] [EXTERNAL] [BULK] Fragmentation in BPv7 Orange Book

Mon Jun 30 07:59:09 UTC 2025

did you mean "not worth" and not "now worth"?

v

On Mon, Jun 30, 2025 at 3:56 AM Tomaso de Cola via SIS-DTN <
sis-dtn at mailman.ccsds.org> wrote:

> Hi Felix, all,
>
>
>
> I definitely agree that at this point in time it is now worth taking back
> to the orange book and make a rework (though light) to address these
> issues, since this would imply a new CESG review, etc., i.e. 1-2 months
> delay in the publication. If necessary we can at some point revise the
> orange book to go for a version 2 of the book, although this is not so
> usual and typically happens with the 5-years review. Or if we want to issue
> recommendations/warning this is something we can go with errata/corrige in
> the same way we did for the LTP reaffirmation to recommend users not to
> implement mixed colours and other aspects of the spec. But also this I’d
> say could be done after the publication of the current version.
>
> The main problem I see in general is that as long as IETF does not fix
> this problem, our blue books cannot really deviate from the existing RFCs
> as we are supposed to have CCSDS profiles of IETF specifications.
>
>
>
> Regards,
>
>
>
> Tomaso
>
>
>
>
>
>
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *Felix
> Flentge via SIS-DTN
> *Sent:* Montag, 30. Juni 2025 08:18
> *To:* Singh, Somendra {Simon} (GSFC-5820) <simon.singh at nasa.gov>; Lars
> Baumgaertner <Lars.Baumgaertner at esa.int>; sis-dtn at mailman.ccsds.org
> *Subject:* Re: [Sis-dtn] [EXTERNAL] [BULK] Fragmentation in BPv7 Orange
> Book
>
>
>
> Hi,
>
>
>
> A couple of points
>
>    1. We should avoid anything which delays the Orange Book further
>    2. The Blue Book shall clearly indicate that CCSDS-compliant
>    implementations shall not ADU-fragment bundles and are not required to
>    re-assemble those even if this makes them technically non Rfc 9171
>    compliant.
>    3. Whether they need to be able to forward fragments, is maybe TBD
>    although I am against this (in practice, we will probably not get
>    implemented).
>    4. IMHO, IETF should update/correct RfC 9171 but this seems to be more
>    complex and nobody seems willing to do right now.
>    5. It would be beneficial if we could get some
>    comment/recommendation/warning about fragmentation in the OB before
>    publication; I think this would be agreeable to the whole WG (and it is
>    ‘just’ an Orange Book) but it might interfere with the CCSDS processes (on
>    the other hand, if CESG/CMC points out that there is a technical problem
>    with fragmentation we might happily change it...).
>
>
>
> Regards,
>
> Felix
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *Singh,
> Somendra {Simon} (GSFC-5820) via SIS-DTN
> *Sent:* 27 June 2025 20:10
> *To:* Lars Baumgaertner <Lars.Baumgaertner at esa.int>;
> sis-dtn at mailman.ccsds.org
> *Subject:* Re: [Sis-dtn] [EXTERNAL] [BULK] Fragmentation in BPv7 Orange
> Book
>
>
>
> Please see my comments below.
>
>
>
> Best regards
>
> Simon Singh
>
> CCSDS SOIS Area Director
>
> CCSDS SOIS-AP WG Chair
>
> NASA/GSFC DTN Systems Engineer
>
>
>
>
>
> *From:* SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> *On Behalf Of *Lars
> Baumgaertner via SIS-DTN
> *Sent:* Friday, June 27, 2025 12:54 PM
> *To:* sis-dtn at mailman.ccsds.org
> *Subject:* [EXTERNAL] [BULK] [Sis-dtn] Fragmentation in BPv7 Orange Book
>
>
>
> *CAUTION:* This email originated from outside of NASA.  Please take care
> when clicking links or opening attachments.  Use the "Report Message"
> button to report suspicious messages to the NASA SOC.
>
>
>
> While looking through the PICS tests in the latest BPv7 OB draft, I was a
> bit confused about the handling of fragmentation in the light of the most
> recent discussions.
>
>
>
>
>
>
>
> Fragmentation itself is OPTIONAL in #31.
>
> #32 is CONDITIONAL as it only makes sense if #31 is implemented.
>
> #34 is OPTIONAL, so BPAs can choose to do on-path ADU reassembly.
>
>
>
> But #33 is MANDATORY, meaning EVERY BPA must support ADU reassembly.
>
> So even if we forbid fragmentation, and the feature at the source node is
> optional, all BPA that want to be compliant must still implement ADU
> reassembly logic and act upon it at the receiving end. This is quite a
> burden, increases attack surface and just seems unnecessary for an optional
> feature and something which might be forbidden per policy in most
> deployments anyhow.
>
>
>
> Here is my interpretation of PICS.33
>
> Every implementation must support ADU reassembly.
>
> Any node can be a destination for fragmentary bundles and the destination
> node of  the these fragmentary (such that they have same srcID, Timestamp,
> Sequence Number, ADU length) is the final chance (actually the only chance
> if we disregard multicasting) to recover the ADU (which the dest node must
> before delivering the ADU.)
>
> Any implementation not supporting ADU reassembly is not compliant with RFC
> 9171.
>
> “Not using fragmentation” recommendation is more like user level
> agreement, rather than something that is baked into the CCSDS books and we
> expect that to change in future.
>
>
>
>
>
> wrt PICS.34
>
> This actually does not make sense since the original bundle is never
> recovered as per RFC 9171, therefore any intermediate node that assembles
> ADU will not be able to forward the bundle and this will not be compliant
> with RFC 9171 forwarding requirements
>
>
>
> Wouldn’t it make sense to make this OPTIONAL as well since consensus now
> seems to be not to do fragmentation at all (at least in the short to mid
> term)?
>
> One could also read the feature description as IF/WHEN doing reassembly
> (which itself is optional) it should then follow the rfc procedures, but
> then it would be CONDITIONAL, right?
>
> Or maybe there is another way to read #33 that I missed…
>
>
>
> Kind regards and have a nice weekend,
>
> Lars
>
>
>
> --
>
> Lars Baumgaertner
>
> Internal Research Fellow (OPS-GAE)
>
> European Space Agency ESA/ESOC
>
> Robert-Bosch-Str. 5, D-64293 Darmstadt
>
>
>
> 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 at esa.int).
>
> 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 at esa.int).
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346

until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250630/36c3c669/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 32107 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250630/36c3c669/attachment-0001.png>