[Sea-sa] SAWG - SCCS-ARD Subset, Minutes of Spring Working Meetings, Meeting 3

Wed May 18 19:44:07 UTC 2022

Dear SCCS-ARD group,

As scheduled we had a 3’rd working meeting of the SAWG on Monday, 16 May, to discuss the SCCS-ARD edits.  Attendees were: Faramaz Davarian, Ed Birrane, Costin Radulescu, Robert Rovetto, Karl Vader, Peter Shames.

Discussion points:

  *   The primary focus of this discussion was to review the significant set of editorial changes needed to bring the SCCS-ARD into alignment with the current set of DTN documents and to have it reflect in the baseline requirements the ability of the published standards to support what the SSI Architecture document, CCSDS 730.1-G-1, calls a Stage 2 deployment, where ground stations, ESLT, actively provide SSI services and directly handle DTN routing and store and forward operations.

  *   “Stage 2 (Internetwork Functionality)—introduction of the SSI protocols into Earth station service providers to enable Network-Layer cross support. The SSI architecture supports this stage by providing internetwork functionality (as described in section 4), which enables the SSI protocols to operate across multiple space flight missions, possibly managed by different national space agencies (interagency cross support). The coordination of mission data communications is still manual at this stage. “

  *   Agreement that the SSI references must be brought into alignment with current SSI/DTN standards, including BPv7 and BPSec.  These are, at present, only available as RFCs (RFC 9171 and RFC 9172).  The CCSDS adaptation profiles are still in development in the DTN WG so we will have to directly reference the RFC’s.
  *   We need to work with the DTN WG to ensure that we accurately reflect the features and services that they plan to include or augment.  We also need to ensure that we align with the security and network management features that they plan to develop in the future.
  *   The working drafts from the IETF for DTN Network Management are still in development.  We were fortunate to have Ed Birrane, who is the lead author on these documents, the Asynchronous Management Architecture (AMA) and the AMA Application Data Model (ADM), and Asynchronous Management Protocol (AMP), present during this meeting to help clarify what we need to address in this document.
  *   Faramaz walked us through the current set of SSI edits in the document.  In many cases there are wholesale parts of the SSI sub-sections that used to all be marked [Future] and that now can be “promoted” to form the heart of new “SSI Stage 2 deployment” sub-sections.
  *   Sec 5, fig 5-2, there was a question about the use of the Data Store that is shown, aside from its use in DTN store and forward operations.  In discussion it was clarified that this can also be used for security purposes, for data quarantine (as needed for diagnostic purposes), for key and identity management, as a local cache for space weather and orbit information, and likely other purposes yet to be identified.
  *   In Sec 5.3.2, pg 5-13, there was a discussion about the existing requirements relating to SSI management.  The agreement is to separate network management, security management, and other aspects like support agreements, policies, and governance into separate requirements.  The document will be revised to address the nascent AMA features and also to identify, separately, that the whole AMA infrastructure consists of functions, protocols & transport, information models and model encoding.  These updates will be made to all the relevant sections and properly reflected in the different Sections (4, 5, and 6).
  *   We agreed to separate out the network management aspects from the newer security related aspects, but to ensure that they are given clear treatment.  As an example of the interplay, there is the realization that network management, itself, is a related set of functions, protocols, data objects, and interfaces that must be secured.  To underscore the importance of this, it cannot be the case, in a Stage 2 deployment with interagency cross support, that any arbitrary node can issue control directives or routing updates.
  *   There was a related discussion about the balance in this SCCS-ARD between adequate coverage of the salient architectural features and not delving too deeply into the details of the standards nor into implementation issues.  Any of these features / functions that have architecturally distinct features should be surfaced, but in a balanced way.
  *   And that discussion (later in the meeting) led to a related discussion of some of the materials that have been added into the ABA sub-sections.  Some of these appear to be verging from “architecturally distinct” down into “implementation significant” territory.   Some judicious edits to the recently updated text may be prudent in order to bring the document into balance and keep it to a manageable size.
  *   There was a somewhat lengthy discussion at different points of all the different possible options that are available to implementers.  For instance, security may be applied at many different levels: application data encryption/authentication, DTN/BPSec, bundle in bundle encapsulation and/or hop-by-hop encryption, link layer using SDLS, etc.  Some or all of these might be applied.  There is a the need, even a requirement, for us to treat this document as the Recommended Practice that it is and to offer clearly documented recommended ways to deal with a typical set of Use Cases.  All features are available, but not all of them may be recommended in the interest of offering both clear guidance and creating an interoperable framework.
  *   We will work to select the best possible approaches for DTN, BPSec, AMA/ADM, etc.  As an example: “AMP shall be used for NW management”.  “ADM models shall be developed (and made available) for any newly adopted standards”.
  *   Security requirements will be included as “should” for Stage 2 deployments, along with a recommended approach for workable “cottage industry” style Key Management, possibly built by leveraging manual SLDS KM techniques (TBD).  Any new interoperable identity and key management standards will be treated as Stage 3 [Future] work.
  *   The SAWG will coordinate with the Cross Support Services Area on whether it is appropriate to reference, in any way, the SLE and CSTS services and associated Functional Resource Model (FRM) for deployment in “ground stations” located on other planetary bodies.  These are called Planet Space Link Terminals (PSLT) in the SCCS-ARD, in parallel to the Earth Space Link Terminals (ESLT, or ground stations).
  *   Sec 5.3.3.4.3 has Future SSI Earth/Planet WAN requirements.  We will need to add new separate SSI requirements for security, security context(s), BPSec, key management, Network Management, Routing/SABR requirements.   Some of these will be current, some will have to be [Future] references.
  *   As with notes for Sec 5.3.3.4.3 we will have to do much the same for a number of other Sec 5 physical element discussions.  We need to scan back through the doc and catch these other fixes.
  *   We need to add AMA and ADM requirements for Services in Sec  4 and related requirements for information models and protocols in Sec 6 as well.
  *   We need to include, early in the doc, a reference to the SSI Architecture document and a short description of the three Stages that are defined.
  *   We need to add a section on Stage 2 SSI Key Management, a description of an acceptable “cottage industry” approach that works with what we now have standardized.
  *   We need to address, in Sec 4 Services, Sec 5 Physical Elements, and in Sec 6 Protocols an adequate description of security policy, bundle encryption handling at intermediate points, key management, and Bundle handling.  This must be “only as much detail as necessary” and avoid excessive detail.  It will be a balancing act, as elsewhere in the document.
  *   Move as much of the Security common requirements to Sec 5.4, which has security for the Physical elements, and only leave those parts that are unique in the earlier parts of Sec 5.
  *   As with the previous note, we will need to do something similar in Sec 6.2.3.7 on Future Secure SSI protocols.  Some will become current, some will be added, and some will remain future.  The current diagrams, which put all of the possible security options into one “omnibus” view, should probably be parsed out into separate diagrams.  User applied encryption/authentication is definitely different in nature and functionality from network level use of BPSec or link layer use of SDLS and we should acknowledge that.
  *   We started to look at Sec 6 to understand the kinds of SSI protocol applicability tables that we will need to develop in order to develop a parallel approach to that used in the ABA sections.  It is acknowledged that this is going to be a lot of work.  We will need to address differences between space and terrestrial deployments and also deal with Security, BPSec, routing, network management, as a set of topics, separate from BP and underlying link deployments.
  *   In doing this review of Sec 6 we also realized (again) that many the revisions made to the Sec 6 ABA tables have exposed a level of detail that may actually be overkill in this architecture document.  For example, a treatment of the possible use of COP, FARM, FOP, and related uplink and downlink CLCW signals to provide reliability might just be stated as such, with a set of requirements and a figure, along with references, but not be allowed to extend into many different figures and descriptions.  This issue has been noted before and bears further scrutiny.  Where do we draw the line between architecturally significant features and implementation options or details?  What can we just identify as an option and then defer to other documents for the details?
  *   Related to the previous note, we need to seek balance across the document, and in particular, between the ABA and SSI sub-sections.  The ABA sub-sections do carry inherently more complexity because of the number of protocols that have been developed over time.  SSI, both with and without security, will have its own complexities.

Action items:

  *   Ed Birrane has stated that he intends to spend more time supporting the updates to the SSI, especially the security and network management, parts of the document as his other tasks roll off.  This contribution to the SSI portions of the document will be very welcome.
  *   Peter to resend the WebEx info for the standing monthly meetings to Ed and Faramaz.
  *   Faramaz to continue working the edits to the SSI parts of Sec 4 & 5, using these, and earlier, notes as guidance.
  *   Costin to continue working the ABA parts of Sec 4, 5, and 6, using these, and earlier, meeting notes as guidance.
  *   Peter to do the first level triage to Sec 6, as was done to Sec 4 & 5, to handle the SSI updates.
  *   Ed to provide the latest drafts of the AMA & ADM draft materials.
  *   Ed to provide recommended language for the new, and [Future], SSI secure network management and operations sections, leveraging the current RFCs and draft AMA materials.
  *   Stated intent is to have a complete draft of the revisions by the end of the FY22 calendar year.
Next Working Session: 21’st Monday in June, 6 June 2022.

Thanks, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20220518/15260e5a/attachment-0001.htm>