[Css-csts] Issue regarding initiator-identifier and responder-identifier

Fri Dec 6 07:07:26 UTC 2019

Hi Erik,
For the business of the initiator identifier and responder identifier we 
noted yesterday the following:

The WG agrees that initiator ID, responder ID and responder port ID are in 
the FR model. Wolfgang will add them for SLE. A comment will be added in 
the semantic definition. John will use that approach as well.
The decision if these parameters (like all parameters) are used for a 
particular MD SI configuration within a service agreement / configuration 
profiles is left to Service Management.

So the FRM will be complete and CSSM will take care when they are used. I 
think this should address your point and to me it feels right to go that 
way.

Best regards,
Holger

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc

From:   "Barkley, Erik J\(US 3970\) via CSS-CSTS" 
<css-csts at mailman.ccsds.org>
To:     "EXTERNAL-Pietras, John V (US 332C-Affiliate)" 
<john.pietras at gst.com>, "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" 
<css-csts at mailman.ccsds.org>, "Wolfgang Hell" <wo_._he at t-online.de>
Cc:     "CCSDS Service Mgmt WG" <smwg at mailman.ccsds.org>
Date:   05/12/2019 23:09
Subject:        Re: [Css-csts] Issue regarding initiator-identifier and 
responder-identifier
Sent by:        "CSS-CSTS" <css-csts-bounces at mailman.ccsds.org>

John et al,

I think this is one of the issues that needs to be coordinated at the area 
level.  As you have noted via your reference to the technote, the CSSM WG 
intends to essentially base the detailed content of the configuration 
profile on the parameters stated in the FRM. It seems to me that it will 
be a substantially non-trivial enough job to pull off without having to 
resort to yet another mechanism other than FRs for stating the various 
initiator and responder identifiers.  I can appreciate the sensitive 
info/security concerns, but I think having the complete model is also 
important.  From the CSSM perspective, it may in fact be more secure if 
this information is carried in the service package – SPDF book -- (via 
modified result data set) such that you could in effect have “rolling” 
identifiers specific for instances that change tracking-pass to 
tracking-pass (assuming that the SP is itself encrypted signed and/or 
block-chained, etc).  I think this might need a broader discussion and so 
I am also copying the CSSM WG for cognizance.  Unfortunately I was not 
able to attend the CSTS WG telecon scheduled for earlier today so perhaps 
this is overcome by events but I just wanted to see if we might come to a 
broader consensus -- I tend to agree with your approach 3.

Best regards,
-Erik 

From: CSS-CSTS <css-csts-bounces at mailman.ccsds.org> On Behalf Of John 
Pietras
Sent: Tuesday, December 3, 2019 08:10
To: CCSDS_CSTSWG (css-csts at mailman.ccsds.org) 
<css-csts at mailman.ccsds.org>; Wolfgang Hell <wo_._he at t-online.de>
Subject: [EXTERNAL] [Css-csts] Issue regarding initiator-identifier and 
responder-identifier

CSTSWG colleagues ---
Recently (perhaps in Darmstadt?) Wolfgang and I discussed whether the 
initiator-identifier and responder-identifier parameters of the 
Association Control procedure should be in the list of configuration 
parameters for a(n) SLE/CS Transfer Service Provider FR. I had envisioned 
including them but Wolfgang has excluded them from his SLE TS Provider FRs 
(FCLTU, RAF, etc.). When we discussed it he stated his belief that they 
should not be in the FR definition because that is sensitive information 
that should not be accessible by, for instance, MD-CSTS. Rather, Wolfgang 
argued, this information should be exchanged by some “other” (not 
specified by CCSDS) means. Conceptually, this other mechanism would 
contain these identifiers in a table that has as a key into it the 
service-instance-identifier, which *is* in the FR definition. In 
particular Wolfgang said that he did not think that these parameters 
should be included in the configuration profiles that would be used for 
scheduling Service Packages. Wolfgang’s argument made sense to me and I 
agreed with his logic, and planned to remove those parameters from the 
CSTS Provider FRs for which I am responsible – Forward Frame, Monitored 
Data, and Tracking Data.

HOWEVER, I now realize that the FF, MD, and TD books *all* identify these 
two parameters as “service management” parameters and assign them their 
service-specific classifiers. The assignment of the classifiers implies 
that these are to be registered as configuration parameters of the 
respective FRs, and there is *no* indication in any of the documentation 
that they are to be treated in a special manner – i.e., be excluded from 
the definition of the FRs that are registered in SANA. 

Off the top of my head, I can think of several ways that we might remedy 
this problem:
Somehow redefine them as some sort of “special” configuration parameters 
(nor “normal” service management parameters) in the FF, TD, and MD service 
specifications. E.g., no classifiers would be specified. This would 
involve tweaking the FF book (relatively easy), TD book (a bit harder 
since it’s already been submitted to the Secretariat) and the MD book 
(involves a TC since it has already been published).
Leave them as configuration parameters of the FRs and add them to the SANA 
Registry FR definitions, but include caveats on their definitions that 
recommend that they not be included in configuration profile and GET-able 
only under highly secure circumstances. This approach (a) has no impact on 
the CSTS books and (b) allows whatever mechanisms that *are* used to 
leverage the existing information architecture – e.g., a privileged, 
secure instance of MD-CSTS could be implemented that would be permitted to 
read these values (e.g., to confirm their real-time setting if the service 
user is having problems binding).
Similar to option 2, leave them as configuration parameters of the FRs and 
add them to the SANA Registry FR definitions, but let the SMWG decide on 
and enforce the restrictions in the Configuration Profile specification, 
and let the Agencies/Providers decide who can read these parameters.
My preference would be for something along the lines of options 2 or 3. 

In a somewhat related topic, there is also the responder-port-id parameter 
that is specified in the existing CSTS specifications as a service 
management parameter. Whatever we decide to do about the 
initiator-identifier and responder-identifier parameters, we need to 
include the responder-port-id parameter as a parameter of FR because it *
does* need to be in the configuration profiles in order to support the 
dynamic allocation method of TCP Socket scheduling that the SMWG wants to 
support (see section 3.4.2 of 
https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Tech%20Note%20Development/Config%20Profile%20Svc%20Agreement%20Tech%20Note/Simplified%20ConfigProfilesAndSvcAgreements_TechNote-v1x4-clean.docx?Web=1
)

I don’t know if we’ll have time to discuss this on Thursday but we do need 
to resolve these issues.

Best regards,
John
 _______________________________________________
CSS-CSTS mailing list
CSS-CSTS at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20191206/9977b099/attachment-0001.html>