[Sis-dtn] FW: CCSDS/IETF coordination on BPv7, BPSec, and ADU fragmentation

[Robert C Durst]

FYSA.  I won't be able to join today's telecon.  I'll try to arrange for
someone to open the line, although our admin is on leave this week -
apologies for my absence and for any disruption it may cause.

 

Best,

Bob

 

From: Robert C Durst 
Sent: Thursday, July 17, 2025 8:07 AM
To: Birrane, Edward J. <Edward.Birrane at jhuapl.edu>; rick.taylor at ori.co
Cc: tomaso.decola <tomaso.decola at dlr.de>
Subject: CCSDS/IETF coordination on BPv7, BPSec, and ADU fragmentation

 

Ed, Rick,

 

I'm writing in my capacity as CCSDS DTN Working Group chair to coordinate
with you regarding operational space mission use of BPv7 and BPSec.  As
we've discussed, operational requirements will not permit the admission of
unauthenticated bundles into the networks being developed for NASA or ESA
missions, in particular (but certainly not limited to) LunaNet.

 

As you know, this requirement, that all bundles must be authenticated by the
BPSec Bundle Integrity Block, is incompatible with the BPv7 ADU
fragmentation capability.  Within CCSDS, we have considered a number of
alternatives to address our very near-term requirement to get a profile
together of BPv7 and BPSec that is consistent with mission security
requirements and practical for implementation from a space mission
perspective.

 

The simplest approach is for us (CCSDS) to simply deprecate BPv7 ADU
fragmentation with requirements such as "CCSDS implementations of BPv7 shall
not produce ADU fragments."  That would avoid the issue of bundle fragments
being generated and avoid the BPSec issue for bundles generated within the
scope of these requirements.  

 

However, per RFC 9171, ADU reassembly is a BPv7 requirement, independent of
ADU fragment creation, and herein lies the issue.  If all bundles must be
signed as a condition of network admission, and ADU fragments cannot be
signed, then no fragments will be in the mission network.  Flight software
is a precious commodity, both in terms of onboard resource consumption and
as a source of possible errors or failures.  Missions will not implement ADU
reassembly; the consensus within the CCSDS DTN WG is that CCSDS should not
require them to.  We can update the BPv7 Protocol Implementation Conformance
Statement pro forma to make ADU fragmentation a "SHALL NOT" and to make ADU
reassembly optional.  However, at least temporarily, this places CCSDS at
odds with the requirements in RFC 9171.  The question from the CCSDS side is
this: since both organizations concur that there is an issue, and that IETF
is working to resolve the issue, does CCSDS establishing this interim
profile cause a problem?  And if so, does IETF have a better alternative?
We look forward to collaborating with you to identify a practicable way
forward.

 

Thanks, and best regards,

Bob Durst

Chair, CCSDS Space Internetworking Services DTN Working Group 

Email:  durst at mitre.org <mailto:durst at mitre.org> 

Cell:  703-217-7414 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250717/23ff8da4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 11785 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250717/23ff8da4/attachment-0001.bin>