[Sls-slp] Regarding the proposed FSH/Insert Zone Changes to AOS, TM, and TC

[Kazz, Greg J (313B)]

SLS-SLPers,

Answers to Marjorie's questions are in RED.

best regards,

Greg Kazz
Chairman SLS-SLP WG chair

Ed and Greg,

I am reviewing your Pink Sheets - so far, I have been looking only at
the book for TM.  There are a few points I have problems with, so this
is a request for some clarification.  I'm new to this security header
stuff, so I could use a bit of help.

1. Context

Are the proposed changes all intended to support the CCSDS security
header for the data link layer?  Or are there some additional purposes?
**Primarily but we thought it was time to clear up the MC_FSH and VC_FSH ambiguity and to release the VC_FSH from the clutches of management and setups.  In other words to fulfill the capability ascribed to the secondary header---announced presence by the flag, and self delimiting like packets**

2. Modifications to VC_FSH Service for TM

The existing VC_FSH service allows the Frame Secondary Header Field to
have different lengths on different VCs within a Master Channel.  The
length is fixed within a VC.

The changes replace the existing fixed-length VC_FSH Service by a new
variable-length VC_FSH Service.  In the new service, the length of the
Frame Secondary Header Field is variable within a Virtual Channel on a
frame-by-frame basis.   As a result, the length of the Transfer Frame
Data Field is also variable on a frame-by-frame basis.  This causes
various problems which I won't go into now.  What is the intended use of
this facility?
***If an implementation relies on the secondary header being of the same length in each frame of a particular VC then the implementation could put constraints on the secondary user to have a fixed size and to be synchronized with the frame generation.  This is a local matter on a spacecraft creator/recipient but does require added complexity for multimission service providers that provide secondary header services. ****

The changes mention having multiple users of the VC_FSH Service within a
VC.  But there is (from the point of view of the TM Space Data Link
Protocol) only one user of the Transfer Frame Data Fields of the frames
within a VC: either the Virtual Channel Packet (VCP) Service or the VCA
Service.  [The VCP service could in theory have more than one user if it
is handling multiple packet types, but even then the packets are placed
into a single stream of frames.]  So, the VC is carrying either:
- a single stream of frames carrying bits of packets, or a single stream of VCA-SDUs.   ***So where is the complexity?  The secondary header service could just like the packet service multiplex multiple secondary headers into a frame (assuming of course that they will not be too long to fit in a single frame-a management issue).  In the security header (which is a secondary header of a specific type we have a bit that signals the presence of another secondary header to follow the security header. ***

Is it likely that the encryption and/or authentication requirements are
going to vary within one of these streams on a frame-by-frame basis?  ***NO**
And if the requirements vary at this level, how can the variable-length
VC_FSH Service contribute to supporting the requirements? How are the
service inputs on different SAPs (VCP and VC_FSH) brought together
inside the TM Space Data Link Protocol entity so that they end up
together in the same frame?  ***The process of building a frame is sequential.  The insert zone is placed followed by the secondary header(s) and then the packet data is inserted. The first header pointer is computed by this later process and the SH flag is set if secondary header data is included.  If one is trying to form the multiplexed packet data field in parallel and just drop it in place then secondary headers need to be constant size.  Again its an implementation issue no a specification issue.****

Would it be an alternative to introduce new services such as VCPsec
Service and VCAsec Service? Here the security requirements could be
parameters on the SAP where the Packets or VCA-SDUs are presented to the
TM Space Data Link Protocol entity.  In performing the service, the
protocol entity could coordinate the generation of the contents of the
Transfer Frame Data Field with the generation of the contents of the
security fields in the FSH.  This avoids having to coordinate separate
SAP requests to the (asynchronous) VCP service and the (synchronous)
VC_FSH Service.  ***This is implementation methodology and we need to investigate it further.  ***

3. Removal of MC_FSH Service and existing form of VC_FSH Service for TM

Clearly, the new facilities proposed in the changes are not
backward-compatible with existing implementations.  This is part of the
price of adding the new link-layer security capabilities.

However, the proposed changes are also removing existing services, such
as the MC_FSH Service from TM.  This introduces a potential future
problem with forward compatibility because new implementations will not
support the removed services. Why not keep the existing MC_FSH Service,
as well as adding the new Master Channel Insert Service?
***We have keep the MC_FSH Service, we just changed its name and remove its influence on the secondary header flag.  This field was a managed field but in presence and length, same as the Insert service. ****

The changes are making substantial changes to existing services, such as
changing the nature of the VC_FSH Service of TM. The service has been
changed but the name has not, which could be confusing in some
circumstances. Why not keep the existing VC_FSH Service, and add a new
service called (for example) Virtual Channel Variable Frame Secondary
Header (VC_VFSH) Service?   *** The present specification provides all the fields to make the VC_FSH service dynamic and flexible (as we have done) but the words constrained it's flexibility for no apparent reason other than simplicity for a earlier era where simplicity was required.***

4.  Cryptographic functions inside the TM Space Data Link Protocol
entity

Section 2.3.1 of 132.0-B Pink Sheets contains a list starting with the
text "The protocol entity performs the following protocol functions".
The changes have added a new entry to the list: "Cryptographic functions
as required utilizing Virtual Channel Secondary Header data."   I didn't
find any further mention of the cryptographic functions in the document.
What is planned in this respect?  How does the protocol entity interface
to any support for the cryptographic activities?  ***Again an implementation issue for which we may have to add text that is similar to the secondary header service implementation text.****

The current Cryptograph service White paper (in the process of being upgraded to a white book) is on the CCSDS CWE.  If you want we can send you the materials on the security service spec as of now.

Best regards,
Marjorie



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20090729/ac0b3f1c/attachment.html>