<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'>SLS-SLPers,<o:p></o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'>Answers to Marjorie’s questions
are in RED.<o:p></o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'>best regards,<o:p></o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'>Greg Kazz<o:p></o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'>Chairman SLS-SLP WG chair<o:p></o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'>Ed and Greg,<br>
<br>
I am reviewing your Pink Sheets - so far, I have been looking only at<br>
the book for TM. There are a few points I have problems with, so this<br>
is a request for some clarification. I'm new to this security header<br>
stuff, so I could use a bit of help.<br>
<br>
1. Context<br>
<br>
Are the proposed changes all intended to support the CCSDS security<br>
header for the data link layer? Or are there some additional purposes?<br>
<font color=red><span style='color:red'>**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**<br>
</span></font><br>
2. Modifications to VC_FSH Service for TM<br>
<br>
The existing VC_FSH service allows the Frame Secondary Header Field to<br>
have different lengths on different VCs within a Master Channel. The<br>
length is fixed within a VC.<br>
<br>
The changes replace the existing fixed-length VC_FSH Service by a new<br>
variable-length VC_FSH Service. In the new service, the length of the<br>
Frame Secondary Header Field is variable within a Virtual Channel on a<br>
frame-by-frame basis. As a result, the length of the Transfer Frame<br>
Data Field is also variable on a frame-by-frame basis. This causes<br>
various problems which I won't go into now. What is the intended use of<br>
this facility?<br>
<font color=red><span style='color:red'>***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. ****<br>
</span></font><br>
The changes mention having multiple users of the VC_FSH Service within a<br>
VC. But there is (from the point of view of the TM Space Data Link<br>
Protocol) only one user of the Transfer Frame Data Fields of the frames<br>
within a VC: either the Virtual Channel Packet (VCP) Service or the VCA<br>
Service. [The VCP service could in theory have more than one user if it<br>
is handling multiple packet types, but even then the packets are placed<br>
into a single stream of frames.] So, the VC is carrying either:<br>
- a single stream of frames carrying bits of packets, or a single stream of
VCA-SDUs. <font color=red><span style='color:red'>***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. ***<br>
</span></font><br>
Is it likely that the encryption and/or authentication requirements are<br>
going to vary within one of these streams on a frame-by-frame basis? <font
color=red><span style='color:red'>***NO**<br>
</span></font>And if the requirements vary at this level, how can the
variable-length<br>
VC_FSH Service contribute to supporting the requirements? How are the<br>
service inputs on different SAPs (VCP and VC_FSH) brought together<br>
inside the TM Space Data Link Protocol entity so that they end up<br>
together in the same frame? <font color=red><span style='color:red'>***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.****<br>
</span></font><br>
Would it be an alternative to introduce new services such as VCPsec<br>
Service and VCAsec Service? Here the security requirements could be<br>
parameters on the SAP where the Packets or VCA-SDUs are presented to the<br>
TM Space Data Link Protocol entity. In performing the service, the<br>
protocol entity could coordinate the generation of the contents of the<br>
Transfer Frame Data Field with the generation of the contents of the<br>
security fields in the FSH. This avoids having to coordinate separate<br>
SAP requests to the (asynchronous) VCP service and the (synchronous)<br>
VC_FSH Service. <font color=red><span style='color:red'>***This is
implementation methodology and we need to investigate it further. ***<br>
</span></font><br>
3. Removal of MC_FSH Service and existing form of VC_FSH Service for TM<br>
<br>
Clearly, the new facilities proposed in the changes are not<br>
backward-compatible with existing implementations. This is part of the<br>
price of adding the new link-layer security capabilities.<br>
<br>
However, the proposed changes are also removing existing services, such<br>
as the MC_FSH Service from TM. This introduces a potential future<br>
problem with forward compatibility because new implementations will not<br>
support the removed services. Why not keep the existing MC_FSH Service,<br>
as well as adding the new Master Channel Insert Service? <br>
<font color=red><span style='color:red'>***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. **** <br>
</span></font><br>
The changes are making substantial changes to existing services, such as<br>
changing the nature of the VC_FSH Service of TM. The service has been<br>
changed but the name has not, which could be confusing in some<br>
circumstances. Why not keep the existing VC_FSH Service, and add a new<br>
service called (for example) Virtual Channel Variable Frame Secondary<br>
Header (VC_VFSH) Service? <font color=red><span style='color:red'> ***
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.***<br>
</span></font><br>
4. Cryptographic functions inside the TM Space Data Link Protocol<br>
entity<br>
<br>
Section 2.3.1 of 132.0-B Pink Sheets contains a list starting with the<br>
text "The protocol entity performs the following protocol functions".<br>
The changes have added a new entry to the list: "Cryptographic functions<br>
as required utilizing Virtual Channel Secondary Header data."
I didn't<br>
find any further mention of the cryptographic functions in the document.<br>
What is planned in this respect? How does the protocol entity interface<br>
to any support for the cryptographic activities? <font color=red><span
style='color:red'>***Again an implementation issue for which we may have to add
text that is similar to the secondary header service implementation text.****<br>
<br>
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.<br>
</span></font><br>
Best regards,<br>
Marjorie<br>
<br>
<br>
</span></font><o:p></o:p></p>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
</div>
</body>
</html>