-
Notifications
You must be signed in to change notification settings - Fork 9
BSL v2.0 TRR
- Agenda
- Review Board
- Software Overview
- Work Product Status (Documents)
- Requirements
- Improvements
- Defect Corrections
- Sustaining Activities
- Other
- Test Objectives
- Test Environment
- Key Test Cases
- Test Personnel
- Test Effort Rationale
- Test Constraint and Risks
- Action Item Status
- Deviations
| Review Board Chair | Jamie Shin |
| MGSS Program Chief Engineer and Task Manager | Kyran Owen-Mankovich |
| SQA Engineer | Lila Baez |
| ASEC SSE & AMMOS Cybersecurity Engineer | Mike Pajevski |
| MGSS Scheduling | Kristin Drucker and Rj Mariano |
| BSL CogE | Madeline Farina |
| BSL Test Lead | Joshua Stone |
| BSL Test Engineer | Will Fei |
| BSL Developer | Brian Sipos |
The BPSec Library (BSL) is a software library (v2.0) and an implementation of Bundle Protocol Security (BPSec), which is the standardized mechanism for BPv7 bundle-layer security as specified in the IETF RFC 9172. The BPv7 transport protocol was developed as part of an overall Delay-Tolerant Networking (DTN) architecture for data exchange in challenging communications environments. BPv7 has been baselined for use in a variety of NASA and other space agency missions such as NASA’s LunaNet and ESA’s Moonlight projects, and has been recommended for a variety of other IOAG and CCSDS space-networked architectures and functions.
The BPv7 protocol data unit is the Bundle, and bundles are comprised of multiple Blocks of information. An application that produces, processes, and/or delivers bundles in compliance with the BPv7 specification is called a Bundle Protocol Agent (BPA). BPSec defines special extension blocks that carry cryptographic information related to other blocks in the same bundle. All standards-compliant BPAs must be able to process BPSec blocks in a received bundle if required by the security policy of the BPA. This project is a BPSec Library (BSL) that implements a general-purpose BPSec security block processor.
Release information for the software can be found in the BSL docs repository.
| Title | Document Number | Status |
|---|---|---|
| BSL TIP | DOC-005726 | Unchanged |
| BSL CONOPS | DOC-005727 | Unchanged |
| BSL SRD | DOC-005735 Rev. A | Released |
| BSL SIS | DOC-005835 | Unchanged |
| BSL Test Plan | DOC-005394 | In review |
| BSL Test Specification Document | DOC-005407 | In review |
The following table is the sections of requirements and how many requirements per section.
| Area | Number of Requirements |
|---|---|
| General (GEN) | 19 |
| Security Service (SSF) | 9 |
| Error and Safety (ERR) | 10 |
| BPA Interface (BIN) | 13 |
| Crypto Interface (CIN) | 5 |
| Policy Interface (PIN) | 6 |
| Telemetry Interface (TIN) | 1 |
| Logging Interface (LIN) | 4 |
| Service (SVC) | 4 |
| Configuration (CFG) | 7 |
| Performance (PFR) | 2 |
| Security (SEC) | 2 |
| Adaptability (ADP) | 4 |
For additional requirement information, please refer to the Verification wiki page. This page was created for the incremental release of BSL (v1.1) and contains the Requirements Traceability Matrix (RTM), which lists the requirement, its description, and the verification procedure. This page also contains other information like a list of test cases that pertain to regression testing.
Note that the GEN line in the table has been updated since last year to be one less requirement (i.e., 19 instead of 20) because requirement BSL-GEN-2-3 has been removed from the SRD.
Specific issues with the enhancement label completed this release cycle:
Total: 13
Specific issues with the bug label completed this release cycle:
| Ticket | Customer | Security-related | Criticality | Release |
|---|---|---|---|---|
| #123 Move log writer thread into host / Mock BPA | no | CRIT-3 | v1.1 | |
| #133 Support memory management through callbacks | no | CRIT-3 | v1.1 | |
| #134 Add ifndef checks to CHK* #defines | no | CRIT-3 | v1.1 | |
| #151 Fix BCB verifier role | yes | CRIT-2 | v1.1 | |
| #197 Fix finalize call in BCB decrypt | yes | CRIT-2 | v1.1 | |
| #209 Logging at DEBUG level always filtered out | yes | CRIT-4 | v2.0 | |
| #212 Security operation option injection susceptibility | no | CRIT-4 | v2.0 | |
| #221 BSL does not cleanly handle unknown context ID | no | CRIT-4 | v2.0 | |
| #230 Crypto key handles need to be reference counted | no | CRIT-4 | v2.0 | |
| #243 Casting size_t to int * in BSL_Crypto_UnwrapKey() is unsafe on Solaris SPARC | ION | no | CRIT-3 | v2.0 |
| #248 Install public headers with fine-grained selection | no | CRIT-4 | v2.0 |
Total: 11
Specific issues with the sustainment label completed this release cycle:
Total: 21
Specific issues with the documentation label completed this release cycle:
| Ticket | Customer | Security-related | Release |
|---|---|---|---|
| #146 Update SRD | no | v2.0 | |
| #147 Update User Guide | no | v2.0 | |
| #223 JSON policy provider: event_set parsed from “root” rather than “policyrule_set” | no | v2.0 | |
| #256 Fix in-source documentation for Sample Policy Provider | no | v2.0 |
Total: 4
Note: RLI #147 "Update User Guide" is still open and therefore not listed in this table because updates to the Product and User Guide are not due until 9/24/2026.
The BSL is a library and the objective of testing is to ensure the library performs its expected behaviors in accordance with the requirements.
The overall purpose is to make test results reproducible for the users. All testing happens as a single library instance on a single "mock BPA" node. There are no requirements or expectations about integrating with any particular real BPA or any multiple node test cases. Certain requirements for the overall environment are as follows:
- Must be RedHat Enterprise 9
- Must have FIPS 140 enabled at OS install
- Must have SE Linux enabled
- Since the BSL software will be configuration managed as rpm packages, the test executor must interact with tests via command prompt/terminal
Note that we describe in more detail the Test Environment in the Acceptance Test Plan.
BSL requirements are verified via two Key Test Cases/Types:
- Mock BPA
- Unit Test
The test team performs black box testing through a simulated Bundle Protocol Agent called the Mock BPA. Testers input a predefined bundle hex string into the Mock BPA and observe the resultant bundle modified by the BSL and outputted by the BPA. An example case for such usage is when a block needs to be removed from a bundle.
Since BSL is a library it contains some functionality that is not visible using the Mock BPA only. For those tests, the test teams reuses unit tests created by the software developers. These unit tests are independently reviewed by the test team to ensure that the tests operate as defined
There are no requirements or expectations about integrating with any particular real BPA or any multiple node test cases.
| Person | Role | Expected Testing Time |
|---|---|---|
| Madeline Farina | Task Manager and Cognizant Engineer | 20 hours |
| Joshua Stone | Test Lead | 40 hours |
| Brian Sipos | BSL Developer | 20 hours |
We expect to spend less time on testing this release cycle compared to BSL v1.0 because we are largely doing regression testing. Note that below it is mentioned tests will take a total time of 72 hours to complete, but we are including a buffer of staff time allocated for identifying the bundles that are needed for the Mock BPA input, dry runs, bug fixes, and review of unit tests. Sufficient budget remains for conducting the testing. All three testers are allocated in the current BSL staff plan for working on this project.
| Milestone | Estimated Date |
|---|---|
| BSL v2.0 Code Freeze | 7/31/2026 |
| TRR | 8/13/2026 |
| Begin test execution | 8/14/2026 |
| End test execution | 9/21/2026 |
| Test Closure Report | 9/24/2026 |
| DDR | 10/8/2026 |
For test effort amount, the estimate is that each test will likely take a minimal amount of time per test execution, e.g. 5 minutes, and there are 86 tests to complete for a total effort of 430 minutes or ~72 staff hours.
There are no external organization dependencies.
Because the BSL is a library and its Mock BPA can operate in isolation, testing doesn't require external systems or resources. The lack of constraints means there are no risks to being able to execute the tests.
The only action item is MGSSAITS-1924 - BSL 1.0 Delivery and Deployment Review (DDR). It has been submitted for closure. All actions associated with the DDR are done. It was awaiting MGSSAITS-1935 - BSL SRD Rev. A update (released 7/13/2026).
The following table contains any RLIs that were completed this release cycle but are not currently in the BSL v2.0 Release Plan (i.e., these RLIs capture any additional work done not initially described in the RP):
Total: 17
Also note that tickets #214, #215, #216, #218, #219, and #231 were completed this release but are not listed in this document, the RP, or the official BSL Status Sheet because they are sub-tickets of #132 "Support for BPSec COSE context" and thereby follow different reporting rules.
This table compares the number of RLIs completed vs. the number of RLIs currently in the revised RP. It illustrates how much additional development was completed this release even accounting for the TPS approved deviations to the revised RP.
| Type | Total # of RLIs in revised RP | Total # of RLIs in this TRR page |
|---|---|---|
| Enhancement | 13 | 13 |
| Defect (bug) | 5 | 11 |
| Sustainment | 12 | 21 |
| Other (documentation) | 3 | 4 |
| Total | 33 | 49 |