[Sls-sea-dls] SDLS Extended Procedures White Book: Open Questions and Inputs

[Daniel.Fischer at esa.int]

Dear all,

Thank you for the input,  Craig  :)

The following major issues (discussions and missing inputs) are still open 
after a brief review and we need to discuss at the meeting:

1) Section 3.4: Service Definitions for Monitoring & Control Services are 
not in line with the service definitions for Key Management and SA 
Management services (level of detail missing). Services parameters 
specification (3.4.2) is OK,  but service procedures (3.4.3) is missing. 
Please take any example from the other services e.g.  3.2.2.5 (Key 
Verification) or 3.3.2.3 (Rekey SA) - BRUNO - MAJOR ISSUE
2) Sections 3.3.2.5 and 3.3.2.6 (Definition of Create SA and Delete SA): 
Service definitions still missing - CRAIG
3) SA Management Service Defiitions: Deactivate SA. It is possible to 
transition only a subset of the channels associated with an SA to a 
different state (e.g. deactivate SA and then only do this for 5 of the 10 
active channels associated with this SA). Is this correct or should 
deactivate SA not allow a list of channels but only the SPI as paramter? 
Because this allows "intermediate states" - TBD  - CRAIG
4) Expire SA as per 3.3.2.4 allows to invoke Deactivate SA, this would be 
a nested procedure execution. Not sure if this is an issue, we need to 
discuss - CRAIG
5) FSR Transfer of sequence number (4.2.2.6.3): I suggest to add a note 
that in some case this means that the FSR carries the 8 LSBs of the IV (in 
case the IV is used as a sequence number)  - ALL
6) 5.5.1: This is just a clarification question. The Master Channel ID is 
unique per communication direction, i.e. the TM and the TC master channels 
have different IDs, right? Otherwise the SA PUDs do not uniquely identify 
the channels to which the SA applies (could be TC or TM)  - ALL
7) Rekey SA PDU (Section 5.5.1.3.2): It is not clear why the PDU has 
fields for two Key IDs (authentication and encryption), both mandatory? 
There should be only one and it should not differentiate between 
authentication and encryption. Even in the case of authenticated 
encryption, there is usually only one key. In case a second one is needed 
for some specific authenticated encryption algorithm, it should be 
optional, or not? Maybe I am missing something.- CRAIG/ALL
8) Create SA PDUs. Not clear why there are 4 PDUs for create SA. Since the 
Create SA procedure is not spelled out as well (see Issue 2), it is not 
possible to understand this. To be clarified. - CRAIG/ALL
9) Section 5.6 requires updating and detailing to align with the Key 
Management and SA Management Sections 5.4 and 5.5. This includes adding 
the Figures for the PDUs - BRUNO - MAJOR ISSUE
10) Baseline mode configurations mising for SA Management and Security 
Management & Control Services  - BRUNO/ CRAIG - MAJOR ISSUE

I will look in more detail at the document in the coming days.

Cheers,
Daniel

Dr. Daniel Fischer
----------------------------
Data Systems Manager
Ground Segment Engineering Support Office (OPS-GE)
Ground Systems Engineering Department
Directorate of Operations

European Space Agency - ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49 (0) 6151 90 2718 - Fax: +49 (0) 6151 90 2718
Web: http://www.esa.int
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/sls-sea-dls/attachments/20160330/1590cb21/attachment.html>