Unspecified Management System: [CESG] Re: Results of CESG Polls closing 14 August 2015
Shames, Peter M (312B)
peter.m.shames at jpl.nasa.gov
Thu Sep 3 12:29:35 UTC 2015
I concur with this version of the document and with the proposed set of edits that resolve the conditions I raised during CESG review.
Regards, Peter
From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>
Date: Tuesday, September 1, 2015 at 6:02 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, "cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>" <cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>>, "howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>" <howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>>
Subject: RE: Unspecified Management System: [CESG] Re: Results of CESG Polls closing 14 August 2015
Dear all,
Attached is an update that includes the proposed text in 6.1, a simplified overview drawing in 2.2, and adds the 355.1 Extended Procedures book to the informative references. Please indicate whether these changes are acceptable.
Regards,
Craig
From: Shames, Peter M (312B) [mailto:peter.m.shames at jpl.nasa.gov]
Sent: Monday, August 31, 2015 9:56 AM
To: Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>
Cc: CCSDS CESG --; cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>; Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]; howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>
Subject: Re: Unspecified Management System: [CESG] Re: Results of CESG Polls closing 14 August 2015
Dear Gippo,
Just to avoid all confusion, this is what I would find acceptable.
On pg 6-1, Sec 6.1
Change:
Through the use of a management system, management conveys the required information to the service provider.
To:
These managed parameters are intended to be included in any service provider system that manages security associations, but no specification for such a management system is provided nor implied.
Regards, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Monday, August 31, 2015 at 3:05 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, "cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>" <cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>>, "Biggerstaff, Craig(JSC-CD221)[LOCKHEED MARTIN CORP]" <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>, "howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>" <howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>>
Subject: Re: Unspecified Management System: [CESG] Re: Results of CESG Polls closing 14 August 2015
Dear Peter,
it is true that the Space Data documents do not specify a management system.
It is also true that the Space Data documents never claim that they specify a management system.
In CCSDS 132.0-B-1.3 the term "management system" is used twice - always in NOTES; i.e. non normative statements - and the second occurrence makes clear that "These parameters are defined in an abstract sense and are not intended to imply any particular implementation of a management system. " Moreover section 1.2 states that this book does not specify "the management activities required to configure and control the protocol."
The same is true for CCSDS 232.0-B-2.2.
The same is true for CCSDS 732.0-B-2.3 with the difference that, dislike 132.0 and 232.0, the mentioning in not in NOTES rather in plain text in the (non normative) section named "OVERVIEW OF MANAGED PARAMETERS".
The same is true for CCSDS 355.0-B-0 with the difference that, dislike 132.0 and 232.0, the first mentioning in not in a NOTE rather in plain text in the (non normative) section named "OVERVIEW" while the second one is a note as for 132.0 and 232.0.
I think all this consistently does "make clear in this section that these are the set of managed parameters that are intended to be included in any system that manages security associations, but that no specification for such a system is provided nor implied."
So adding a word (i.e. unspecified) in a single book is not necessary and would not cure the problem you see.
Having said this I do continue supporting the WG in rejecting this particular condition at this point in time.
Best regards
Gian Paolo
PS It may be that in the future the WG's will work and agree to e.g. adding an exhaustive non normative annex that explains with more details the limitations and issues you see in the current versions.
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
To: "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>,
Cc: "CCSDS CESG --" <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, "howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>" <howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>>, "Biggerstaff, Craig\(JSC-CD221\)\[LOCKHEED MARTIN CORP\]" <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>
Date: 29/08/2015 01:41
Subject: Re: Unspecified Management System: [CESG] Re: Results of CESG Polls closing 14 August 2015
Sent by: cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>
________________________________
Ciao Gippo,
The issue I have with how this Management System is specified in these documents is that it is not really specified at all as a system. It is, instead, described in Sec 6 as a set of managed parameters. This is useful, since it does provide the implementer with some concrete guidance on what is expected to be managed and a possible range of values, but it does not constitute a Management System. There is no spec for the system, no defined behavior for the system, and no interfaces for the system, not even in the abstract.
I would recommend, therefore, that you make clear in this section that these are the set of managed parameters that are intended to be included in any system that manages security associations, but that no specification for such a system is provided nor implied.
CCSDS does indeed provide service systems, interface, and behavioral specifications. The most prominent of these are the SLE and CSTS, but even the MOIMS SM&C is starting to develop system interfaces. The RASIM also provided a set of abstract system interfaces. Specs such as CFDP and AMS have defined the service characteristics of a data management service that is intended to do buffer management within the protocol. I find none of the typical characterizations of a system or service interface in this spec, only a set of data items that consititue managed parameters.
I would not in any way suggest that we list in every spec all the things that they are not. That would be foolish. At the same time I think we need to be careful to be clear in describing what it is that we do define and what the limitations are.
Best regards, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Friday, August 28, 2015 at 12:39 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>, "howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>" <howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: Unspecified Management System: [CESG] Re: Results of CESG Polls closing 14 August 2015
Dear Peter,
I am extremely reluctant to accept your condition about adding the term "unspecified" in front of "management system".
First of all Craig motivated the non addition of this term in his WinWord comment stating <Using the word 'unspecified' for management in section 6.1 is not consistent with the language used with the SLP BBs. Each of the four standards (SDLS, TC, TM, AOS) contains a statement in section 1.2 where the absence of specification for the management activities is stated. Otherwise, the word 'unspecified' does not show up a single time in TC, TM and AOS BBs.
The WG prefers to be consistent with the SLP books, and proposes not to add the word 'unspecified' here.>
Moreover if we accept this trend than each CCSDS document will need to add the term unspecified in front of whatever is not specified in that document or outside.
It is also not fully true that the management is unspecified, actually chapter 6 itself contains a number of requirement (not all requirements, indeed) to be used when specifying the (agency specific) management system.
Last but not l;east, CCSDS never specifies systems but rather provide standards to be used for a subset (sometimes large) of the systems specification to be issued by a given Agency/Company.
So I do recommend keeping consistency within the documents of the SLS Area and not adding the term "unspecified" in front of "management system" and I kindly ask you to withdraw this specific condition.
Best regards
Gian Paolo
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
To: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>, "Scott, Keith L (9730-Affiliate)" <kscott at mitre.org<mailto:kscott at mitre.org>>, "tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>" <tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>>,
Cc: "howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>" <howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>>, "cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>" <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Date: 28/08/2015 02:48
Subject: [CESG] Re: Results of CESG Polls closing 14 August 2015
Sent by: cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>
________________________________
Dear Craig, et al,
I have reviewed the proposed changes to the document. I find all of them acceptable except for one. I really believe that this document will better represent its functions if a new, simplified, version of "figure 6-1” is included in sec 2.2.2. This would allow you to introduce in a graphical way exactly what this protocol does relative to the three space data link protocols. You can then point to the protocol specific versions as you have.
And on pg 6-1, sec 6.1 there was a side note about the "management system” being unspecified. I propose changing the text to read "Through the use of an out of band and unspecified management system…"
I think that gets the flavor of what you are describing. Would you agree?
There is this further loose end having to do with the “still in work” CCSDS SDLS Extended Procedures recommendation (reference 355.1-B). It is mentioned twice in the document in NOTE and overview text. Since it is not final this is probably appropriate. Tom Gannett will probably have an opinion about this, but I think you could insert a reference to the Red Book in the non normative references and mark it as [Future}. We did that on the SCCS-ARD and no one screamed, and it at least gets a clear reference to the “to be published” standard into the document.
Best regards, Peter
From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>
Date: Thursday, August 27, 2015 at 4:16 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Keith Scott <kscott at mitre.org<mailto:kscott at mitre.org>>, "tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>" <tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, Gilles Moury <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>, "howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>" <howie.weiss at sparta.com<mailto:howie.weiss at sparta.com>>
Subject: RE: Results of CESG Polls closing 14 August 2015
Dear ADs/DADs,
As the book editor of CCSDS 355.1-B-0 'Space Data Link Security Protocol', I have attached proposed text changes that, the WG believes, will resolve your CESG poll conditions. Please review these changes and let me know if the changes answer your requirements. Thank you.
Best regards,
Craig Biggerstaff
At 03:37 PM 8/17/2015, CCSDS Secretariat wrote:
CESG E-Poll Identifier: CESG-P-2015-07-001 Approval to publish CCSDS
355.0-B-1, Space Data Link Security Protocol (Blue Book, Issue 1)
Results of CESG poll beginning 31 July 2015 and ending 14 August 2015:
Abstain: 0 (0%)
Approve Unconditionally: 6 (66.67%) (Merri, Behal, Calzolari,
Moury, Suess, Barton)
Approve with Conditions: 3 (33.33%) (Shames, Scott, Cola)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Peter Shames (Approve with Conditions): We need this document to be
published, and soon, but there are still a few inconsistencies that
I believe should be fixed before that happens. There are marked in
the attached text, but I will summarize them here:
1) The document is missing a really good overview description and
figure showing the relationship of the user provided transfer frame
data field to the secured field. Such figures are in docs like CCSDS 232x0b.
What you are asking for was originally in the SDLS Red Book but was moved to the TC/TM/AOS Pink Books. The WG would prefer to reference those books instead of duplicating the overview information.
2) related to 1), the term "payload" is defined in sec 1.6, but it
is then not used in any consistent way within the rest of the
document. And the definition of the word "payload" is disjoint from
other CCSDS usage. The word "package" or "user provided data" might be better.
The use of "Payload" in this document follows its common use within cryptography. Its meaning within the context of this document has been defined in 1.8, and it is now capitalized as a proper name throughout. The WG believes this will clear up any confusion.
3) The Security Association Management Service, sec 3.4, reads like
Green Book material, not Blue Book. There is not even an abstract
service spec provided and as such it appears to be non-normative
content. The related "Primitives" are not even sketched out, which
makes this section look even more "unfinished".
The WG's consensus was that specifying only the required Security Association managed parameters was sufficient for 355.0, which the WG wanted to keep 'lightweight'. The WG did originally consider a set of service primitives covering SA management, but decided that including them in the 355.0 core protocol would unduly constrain operations centers to a particular state model for operational key changes and recovery from spacecraft failures, where is not now any consensus to reverse agency-specific approaches. Those subjects were deemed material for the Green Book or else for the SDLS Extended Procedures Blue Book.
4) There is a repeated description of "Rollover of the sequence
number could be used to signal the end of the acceptable lifetime of
a cryptographic key", which sounds like specific guidance, but
always appears in a NOTE. This might be better expressed in a real
requirement as a "may".
The NOTEs have been modified to eliminate any guidance and to refer to the GB.
Keith Scott (Approve with Conditions): I concur with Tomaso that a
note stating the non-applicability of this specification to
Proximity-2 communications would be quite helpful.
Tomaso de Cola (Approve with Conditions): As the book relates to
security implemented in the data link layer of CCSDS protocol stack,
I would expect a note or comment in Section 1 to state that the
scope of the book is limited to AOS, TM, and TC and does not address
Proximity. Finding no mention of proximity leaves some uncertainty
on the overall security implementation in SDLP.
A statement to this effect has been added to paragraph 2.1.
Note for future book amendments, the green book CCSDS 350.0-G-2 (THE
APPLICATION OF CCSDS PROTOCOLS
TO SECURE SYSTEMS ) will probably require some minor revision to
reflect the changes provided in this blue book, once published.
Total Respondents: 9
No response was received from the following Area(s):
CSS
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions
PROPOSED SECRETARIAT ACTION: Generate CMC poll after
conditions have been addressed
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org<mailto:CESG at mailman.ccsds.org>
http://mailman.ccsds.org/mailman/listinfo/cesg
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org<mailto:CESG at mailman.ccsds.org>
http://mailman.ccsds.org/mailman/listinfo/cesg
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150903/6e8a7005/attachment.html>
More information about the CESG
mailing list