[Cesg-all] Results of CESG Polls closing 14 August 2015
CCSDS Secretariat
tomg at aiaa.org
Mon Aug 17 19:37:41 UTC 2015
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.
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.
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".
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".
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.
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 E-Poll Identifier: CESG-P-2015-07-002
Approval to publish CCSDS 132.0-B-2, TM Space
Data Link Protocol (Blue Book, Issue 2)
Results of CESG poll beginning 31 July 2015 and ending 14 August 2015:
Abstain: 0 (0%)
Approve Unconditionally: 7 (77.78%) (Merri,
Behal, Scott, Calzolari, Moury, Suess, Barton)
Approve with Conditions: 2 (22.22%) (Shames, Cola)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Peter Shames (Approve with Conditions): This is
approved with one condition: Add references to
the SCCS-ADD (CCSDS 901.0-G) and SCCS-ARD
(901.1-M) to section 2.1.1 Architecture where the OSCP is also included.
Also, note that the term "payload", which is used
(inconsistently) in the SDLS document (CCSDS
355x0b) does not appear anywhere in this document.
However, Figure 6-1 does make the relationships
among User Data, Transfer Frame Data Field, and
Security Header and Trailer quite clear without using this term.
Keith Scott (Approve Unconditionally): In
principle I concur with Tomaso that the reference
to the SDLS book should be updated to reflect the
published version of the SDLS Blue Book (provided
that the SDLS Blue Book is approved in the same
round of polling as TM). This assumes that there
are no substantive differences between the draft
SDLS book referenced here and the final SDLS
book, which I believe is the case; however, a
comment on this by the Security WG might be useful.
--keith
Tomaso de Cola (Approve with Conditions): I would
suggest to update reference (normative) 10, so
that issue 1, instead of issue 0 appears.
Obviously, the "code" of the referenced CCSDS
book should be updated accordingly as well.
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 E-Poll Identifier: CESG-P-2015-07-003
Approval to publish CCSDS 232.0-B-3, TC Space
Data Link Protocol (Blue Book, Issue 3)
Results of CESG poll beginning 31 July 2015 and ending 14 August 2015:
Abstain: 0 (0%)
Approve Unconditionally: 7 (77.78%) (Merri,
Behal, Scott, Calzolari, Moury, Suess, Barton)
Approve with Conditions: 2 (22.22%) (Shames, Cola)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Peter Shames (Approve with Conditions): This is
approved with one condition: Add references to
the SCCS-ADD (CCSDS 901.0-G) and SCCS-ARD
(901.1-M) to section 2.1.1 Architecture where the OSCP is also included.
Also, note that the term "payload", which is used
(inconsistently) in the SDLS document (CCSDS
355x0b) does not appear anywhere in this document.
However, Figure 6-1 does make the relationships
among User Data, Transfer Frame Data Field, and
Security Header and Trailer quite clear without using this term.
Keith Scott (Approve Unconditionally): In
principle I concur with Tomaso that the reference
to the SDLS book should be updated to reflect the
published version of the SDLS Blue Book (provided
that the SDLS Blue Book is approved in the same
round of polling as TC). This assumes that there
are no substantive differences between the draft
SDLS book referenced here and the final SDLS
book, which I believe is the case; however, a
comment on this by the Security WG might be useful.
--keith
Tomaso de Cola (Approve with Conditions): As
stated for TM book, the reference to SDLS blue
book should be with issue 1, instead of 0.
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 E-Poll Identifier: CESG-P-2015-07-004
Approval to publish CCSDS 732.0-B-3, AOS Space
Data Link Protocol (Blue Book, Issue 3)
Results of CESG poll beginning 31 July 2015 and ending 14 August 2015:
Abstain: 0 (0%)
Approve Unconditionally: 8 (88.89%) (Merri,
Behal, Scott, Cola, Calzolari, Moury, Suess, Barton)
Approve with Conditions: 1 (11.11%) (Shames)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Peter Shames (Approve with Conditions): This is
approved with one condition: Add references to
the SCCS-ADD (CCSDS 901.0-G) and SCCS-ARD
(901.1-M) to section 2.1.1 Architecture where the OSCP is also included.
Also, note that the term "payload", which is used
(inconsistently) in the SDLS document (CCSDS
355x0b) does not appear anywhere in this document.
However, Figure 6-1 does make the relationships
among User Data, Transfer Frame Data Field, and
Security Header and Trailer quite clear without using this term.
Keith Scott (Approve Unconditionally): In
principle I concur with Tomaso that the reference
to the SDLS book should be updated to reflect the
published version of the SDLS Blue Book (provided
that the SDLS Blue Book is approved in the same
round of polling as AOS). This assumes that there
are no substantive differences between the draft
SDLS book referenced here and the final SDLS
book, which I believe is the case; however, a
comment on this by the Security WG might be useful.
--keith
Tomaso de Cola (Approve Unconditionally): As
stated for the TM book, the reference to SDLS
blue book should be with issue 1, instead of 0.
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 E-Poll Identifier: CESG-P-2015-07-005
Approval to publish CCSDS 130.2-G-3, Space Data
Link Protocols—Summary of Concept and Rationale (Green Book, Issue 3)
Results of CESG poll beginning 31 July 2015 and ending 14 August 2015:
Abstain: 0 (0%)
Approve Unconditionally: 6 (75%) (Merri,
Behal, Calzolari, Moury, Suess, Barton)
Approve with Conditions: 2 (25%) (Shames, Cola)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Peter Shames (Approve with Conditions): This
document still needs a significant amount of work. Here are the major issues:
1) It talks about the role of Service Providers
in a number of places, but the SLE interfaces,
and the role of space data service providers, is
essentially ignored. The only SLE service that is
included is FSP, CLTU, RAF and RCF are all left out, a major omission.
2) Prox-1 is left out, but spacecraft to
spacecraft links are mentioned in several places.
This tends to suggest that these links should be
serviced by TC & TM, which is not typically the best approach.
3) AOS is described only in the context of audio
and video services, its use for high rate data links is not even mentioned.
4) RASDS diagrams are used throughout, but there
is no reference made to RASDS (CCSDS 311.0-M).
References should also be made to the SCCS-ADD
(CCSDS 901.0-G) and the SCCS-ARD (CCSDS 901.1-M).
These documents provide the best context for
understanding the relationships among all of
these SLS protocols and the CSS services.
5) The treatment of COP, FOP, FARM is a little
uneven and no mention is made of LTP as a means
to assure reliable delivery of link layer data.
6) The only "network" protocols that are
mentioned are SPP (and a little about Encap).
There is not mention of other CCSDS upper layer
protocols like LTP, CFDP, AMS, IP or DTN. These
application layer and network layer protocols are
a part of CCSDS and their relationship to the link layer should be made clear.
Tomaso de Cola (Approve with Conditions): Three comments:
1) reference to SDLS (reference [21]) should be updated to issue 1.
2) In section 2 it is stated that proximity-1 is
out of the scope of the book, because a separated
green book is already available about
proximity-1. I'd place a similar statement also
in section 1.2, where actually the scope of the book is established.
3) In section 5.2, it is mentioned that
proximity-1 does not have specific security
requirements. Since the book does not address
Proximity-1, I would drop this consideration.
Total Respondents: 8
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 E-Poll Identifier: CESG-P-2015-07-006
Approval to release CCSDS 509.0-R-1, Pointing
Request Message (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 31 July 2015 and ending 14 August 2015:
Abstain: 1 (14.29%) (Calzolari)
Approve Unconditionally: 4 (57.14%) (Merri, Behal, Suess, Barton)
Approve with Conditions: 2 (28.57%) (Barkley, Shames)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Erik Barkley (Approve with Conditions): Some conditions and some comments.
Conditions:
1) CCSDS has defined a URN for, among other
things, management of XML Schemas. As such a no
namespace schema is not really allowed. The XML
Schema (or sub-schemas depending on desired
organization) need to have a namespace definition.
2) SANA considerations part 1: In addition to
registering the schema (which is good), the
recommendation makes use of data items for which
there are controlled CCSDS registries. This includes such items as:
a) spacecraft name (http://sanaregistry.org/r/spacecraftid/spacecraftid.html)
b) Originator -- there is a registry in progress
for this http://sanaregistry.org/r/organizations/organizations.html
But these are not called out in the SANA considerations sections.
3) SANA considerations part 2: -- by definition,
WGs are not supposed to be standing bodies within
CCSDS. That being the case a different management
policy for registration control authority for
controlled information that can outlive a working
group other than communication the WG chair
should to be stated. It is suggested to contact
the CCSDS SE Area for a better definition of this
as SANA registry policy is currently being revised by the SE Area.
Comments (not conditions):
1) Although the principal investigator and relay
communications are cited as use cases, its not
clear how this fits a with a bigger picture of
mission operations in general. Is the PRM really
something to be emitted by a PI? Presumably the
antenna pointing on-board the spacecraft is in
fact then further sequenced as part of an overall
spacecraft operations planning taking into
account keep-out zones, spacecraft fault
protection etc. Perhaps this may just be an issue
of terminology -- its seems that is not really a
request to point an antenna but really a request
to have the spacecraft antenna track a particular
target or motion pattern? It would be interesting
to learn more of the conceptual background and
how this fits with the overall MOIMS architecture.
Peter Shames (Approve with Conditions): This
document is quite mature, but it contains a
significant number of issues that should be
resolved before it goes out for agency review. Key issues:
1) Two annexes are marked information but contain
what appears to be normative materials
2) There are a number of points at which
references are made to "do it in an ICD" instead
of providing clear definitions. A means of
providing extensibility points, and even a SANA registry, would be prefered.
3) There are a number of items, such as
"originator", "spacecraft", or other identifiers
that are weakly specified. Where possible
existing SANA registries should be referenced.
4) There are many terms used in this spec that
are not defined or not adequately defined.
5) There is no ICS.
See the attached document for additional comments
and specific suggestions for remedying these issues.
Total Respondents: 7
No response was received from the following Area(s):
SIS
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions
PROPOSED SECRETARIAT ACTION: Generate
CMC poll after conditions have been addressed
* * * * * * * * * * * * * * * * * * * * * * * *
More information about the CESG-All
mailing list