[Sls-slp] FW: [EXTERNAL] RE: Your feedback on an SLP WG Proposal to secure USLP directives/reports (but not COP-P commands)

Mon Oct 19 13:12:29 EDT 2026

Dear SLP WG,

Sharing with the entire SLP WG distribution list. We will discuss this topic at tomorrow's meeting in the afternoon - Central European Summer Time.

Best regards,
Greg

From: Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] <brent.r.andres at nasa.gov>
Sent: Monday, October 19, 2026 10:05 AM
To: Howard.Weiss at parsons.us; KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>; Biggerstaff, Craig T. (JSC-CD111) <craig.biggerstaff at nasa.gov>
Cc: matt.cosby at goonhilly.org; Stefano Petri <stefano.petri at esa.int>; Saba Bruno <bruno.saba at cnes.fr>
Subject: RE: [EXTERNAL] RE: Your feedback on an SLP WG Proposal to secure USLP directives/reports (but not COP-P commands)

Hi Howie,

I appreciate your feedback.  My goal with this approach was to make little to no change to SDLS or the order of operations.  In thinking about securing non-cop P frames I separated them conceptually into P frames sent on the hailing channel and p frames used for session management on the working channel.  For that latter case if they were secured it made sense to me to place them on a unique vcid/gmap_id, both to increase security and also to avoid the nonce counting issue that would exist if an existing (data carrying) vcid was used and that's why I included slide 4 in the overview section, so that people would know what I was referring to.  Alternatively, one could leave those P frames (on the working channel) un-secured but then the books and the hardware would need to distinguish between P frames being sent to establish a channel (hailing) and those being sent to manage it (working) and I decided to propose securing them in the same way on the working channel.  Dedicating that unique VCID/MAP id to a relay compartmentalizes the security to a limited degree but also allows the relay to know whether it should respond to a User hailing it (UIS).  The Source ID would be in the transfer frame header and the relay destination would be implied by the vcid/map id without the relay having to decrypt the data field.  The intended relay would respond and all other relays would ignore the hail to avoid response collision.

The presence or absence of a clear channel for network control (P frame directives) is a significant consideration.  My feeling was that on balance it's better to secure it rather than leave it open to attack and it's also better to compartmentalize the security to the maximum extent possible.  With this approach it should be possible to have unique keys for each relay, providing a limited firewall.  I say limited because the users will obviously have access to all of the relay keys that they need (but at the moment no keys are needed for network control at all).  User keys will remain known only to users and should one relays keys be compromised the other relays keys would not.

Brent

[cid:image001.png at 01DD5FC0.3A32A4E0]

Brent Andres
Chief Staff Engineer 4
Columbus Technologies and Services, Inc.
NASA GSFC B23/W124
c: (540) 385-1910
brent.r.andres at nasa.gov<mailto:brent.r.andres at nasa.gov>

From: Howard.Weiss at parsons.us <Howard.Weiss at parsons.us>
Sent: Monday, October 19, 2026 11:27 AM
To: KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>; Biggerstaff, Craig T. (JSC-CD111) <craig.biggerstaff at nasa.gov>
Cc: matt.cosby at goonhilly.org; Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] <brent.r.andres at nasa.gov>; Stefano Petri <stefano.petri at esa.int>; Saba Bruno <bruno.saba at cnes.fr>
Subject: [EXTERNAL] RE: Your feedback on an SLP WG Proposal to secure USLP directives/reports (but not COP-P commands)

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.

+ Bruno Saba

Greg/Brent,

Sorry for not responding - simply lack of time prior to the trip.  Thanks for pinging....

I understand the issue of the control commands not being secured....

There is a good discussion in the GB in section 3.1.1. I remember lots of discussions on the order of operation and there was a good reason for putting SDLS in the published order. I know that we spent a lot of time debating what is and what is not protected to maintain compatibility to our best abilities as shown in the Green Book.

This issue is akin to emergency mode commands being sent in the clear (e.g., safe mode commanding).  For EM there is no 'right' answer.'  If it's protected, it might not get acted on because the spacecraft can't process the protected command.  If it's not protected, it could be abused and could be a risk to the mission.

Based on my very minor understanding of COP/FOP/FARM, it would appear to me that the proposal is reasonable, if the mission find the risk is not acceptable.  But I little enough to be quite dangerous!  We were concerned about SDLS breaking COP operation which resulted in it not being secured.

Bruno/Craig/Matt - comments?

howie

From: KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>
Sent: Monday, October 19, 2026 10:41 AM
To: Biggerstaff, Craig T. (JSC-CD111) <craig.biggerstaff at nasa.gov>; Weiss, Howard [US-US] <Howard.Weiss at parsons.us>
Cc: matt.cosby at goonhilly.org; Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] <brent.r.andres at nasa.gov>; Stefano Petri <stefano.petri at esa.int>
Subject: [EXTERNAL] Your feedback on an SLP WG Proposal to secure USLP directives/reports (but not COP-P commands)

Hi Craig/Howie,

Attached is the presentation that Brent Andres will give in the SLP WG meeting in the later afternoon (around 3:30 ish).

Can we get your SDLS feedback on it please ?

We are specifically concerned that CCSDS Session Control (235.1) directives need to be secured by SDLS, "someone could send non-secured directives on the hailing channel (or working channel after link establishment), and create self-interference or send an incorrect time distribution directive right before a critical operation.  In essence, right now the data is SDLS-secure (USLP U-frames)  but network control frames (P-frames) by SDLS are not. See the presentation for more details.

Thanks much,
Greg & Brent

"NOTICE: This email message and all attachments transmitted with it may contain confidential information, including information that is privileged or protected by, and proprietary to, Parsons Corporation, and is intended solely for the use of the addressee for the specific purpose set forth in this communication. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited, and you should delete this message and all copies and backups thereof. The recipient may not further distribute or use any of the information contained herein without the express written authorization of the sender. If you have received this message in error, or if you have any questions regarding the use of the proprietary information contained therein, please contact the sender of this message immediately, and the sender will provide you with further instructions."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20261019/094bb985/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5794 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20261019/094bb985/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 356 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20261019/094bb985/attachment-0003.png>