[Sls-sea-dls] Fw: Question regarding the SDLS EP Standard

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Wed Apr 12 09:04:15 UTC 2017


Daniel,
        SLP is not meeting on Wednesday and I think they have a priority 
for USLP discussion on Thursday.
Of course Greg can be more precise than me, but he already pointed out the 
initial intention  to address it during the SLP WG meeting on Friday AM.
Moreover Wednesday afternoon some SLP members will be attending the DTN 
meeting.

You may want to investigate who could attend it Friday AM to see if there 
is a kind of quorum.

Just my cent....

Gian Paolo





From:   Daniel Fischer/esoc/ESA
To:     Gian Paolo Calzolari/esoc/ESA at ESA
Cc:     "Greenberg, Edward (312B)" <edward.greenberg at jpl.nasa.gov>, "Moury 
Gilles" <Gilles.Moury at cnes.fr>, "Kazz, Greg J (312B)" 
<greg.j.kazz at jpl.nasa.gov>, "sls-sea-dls at mailman.ccsds.org" 
<sls-sea-dls at mailman.ccsds.org>
Date:   12/04/2017 07:15
Subject:        Re: [Sls-sea-dls] Fw:  Question regarding the SDLS EP 
Standard


Dear all,

I would be still there on Friday but it may be better to have the 
discussion on Wednesday or Thursday when the SDLS group meets as well. I 
fear that some people might be gone already on Friday.

Cheers,
Daniel

Dr. Daniel Fischer
Head of the Engineering Support Section, OPS-GES
Ground Systems Engineering Department
Directorate of Operations
ESA - ESOC
Robert-Bosch-Str. 5, D-64392 Darmstadt, Germany
Tel. +49 6151 90 2718 |  E-mail: Daniel.Fischer at esa.int




From:   Gian Paolo Calzolari/esoc/ESA
To:     "Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>
Cc:     "Moury Gilles" <Gilles.Moury at cnes.fr>, Daniel 
Fischer/esoc/ESA at ESA, "Greenberg, Edward (312B)" 
<edward.greenberg at jpl.nasa.gov>, "sls-sea-dls at mailman.ccsds.org" 
<sls-sea-dls at mailman.ccsds.org>
Date:   11/04/2017 19:32
Subject:        Re: [Sls-sea-dls] Fw:  Question regarding the SDLS EP 
Standard



If you do that first thing on friday am somebody from sdls may be able to 
attend too. 

Sent from my iPhone

On 11 Apr 2017, at 18:37, Kazz, Greg J (312B) <greg.j.kazz at jpl.nasa.gov> 
wrote:

I think it is a good proposal and it is a topic we will address during the 
SLP WG meeting on Friday AM and perhaps also it could be discussed during 
the SDLS meeting on Wed.
However, we don?t have a SLS area joint meeting scheduled in San Antonio. 
Perhaps we could take some time on Friday afternoon in the SLS plenary to 
come up with a joint way forward based upon the discussions in those other 
two forums.
 
G.P. ? what do you think?
 
Thanks!
Greg
 
From: Moury Gilles <Gilles.Moury at cnes.fr>
Date: Tuesday, April 11, 2017 at 4:08 AM
To: "Daniel.Fischer at esa.int" <Daniel.Fischer at esa.int>, "Greenberg, Edward 
(312B)" <edward.greenberg at jpl.nasa.gov>
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov>, "sls-sea-dls at mailman.ccsds.org" 
<sls-sea-dls at mailman.ccsds.org>, Calzolari Gian-Paolo <
Gian.Paolo.Calzolari at esa.int>
Subject: RE: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard
 
Dear Ed,
 
I tend to agree with Daniel : this problem of GVCID ambiguity for 
bidirectional spacelinks is a general problem that will be encountered not 
only by SDLS EP (for SA management procedures) but also for all 
bidirectional protocols like AOS, USLP for which GVCID does not carry the 
direction (forward or return) of the VC we are dealing with. The solution 
you propose to introduce 2 new IDs (GVCIDS, GVCIDR) would solve the 
ambiguity but needs to be agreed SLS-wide. Greg and Gian-Paolo: what is 
your opinion ?
 
Best regards,
 
Gilles
 
Gilles MOURY 
CNES Toulouse 
De : Daniel.Fischer at esa.int [mailto:Daniel.Fischer at esa.int] 
Envoyé : mardi 11 avril 2017 12:32
À : Greenberg, Edward (312B)
Cc : Moury Gilles; Kazz, Greg J (312B); sls-sea-dls at mailman.ccsds.org
Objet : RE: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard
 
Dear Ed, 

Sorry for not coming back to you earlier. I think we will discuss your 
recommendation in the upcoming meetings. 
In my opinion the scope of the impact of the new definitions of the 
GVCIDR/S is not limited to SDLS or SDLS Extended Procedures and needs to 
be discussed in a wider frame. 

Cheers, 
Daniel 

Dr. Daniel Fischer
Head of the Engineering Support Section, OPS-GES
Ground Systems Engineering Department 
Directorate of Operations 
ESA - ESOC
Robert-Bosch-Str. 5, D-64392 Darmstadt, Germany 
Tel. +49 6151 90 2718 |  E-mail: Daniel.Fischer at esa.int 



From:        "Greenberg, Edward (312B)" <edward.greenberg at jpl.nasa.gov> 
To:        Moury Gilles <Gilles.Moury at cnes.fr>, "Daniel.Fischer at esa.int" <
Daniel.Fischer at esa.int>, "sls-sea-dls at mailman.ccsds.org" <
sls-sea-dls at mailman.ccsds.org> 
Cc:        "Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov> 
Date:        11/04/2017 01:36 
Subject:        RE: [Sls-sea-dls] Fw:  Question regarding the SDLS EP 
Standard 




I never had a response to my recommendation.  I made this recommendation 
for compatibility with AOS, proximity 1 and USLP since these protocols can 
be used in both directions thus the PVN is not a discriminator.   TM and 
TC have a 2 bit PVN and they are both ?00?. 
  
From: Greenberg, Edward (312B) 
Sent: Friday, March 31, 2017 2:24 PM
To: 'Moury Gilles'; Daniel.Fischer at esa.int; sls-sea-dls at mailman.ccsds.org
Subject: RE: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard 
  
The SCID identifies the Spacecraft.  The SOURCE/DESTINATION FLAG 
identifies the sending side or the receiving side.  Thus by including the 
SOURCE/DESTINATION FLAG into the GVCID/GMAPID you determine the sending 
side GVCID verses the receiving side GVCID.  By simply modifying the term 
GVCID to GVCIDS for the sending side and GVCIDR for the receiving side you 
separate the VCs by directionality which is exactly what you want.   
  
From: SLS-SEA-DLS [mailto:sls-sea-dls-bounces at mailman.ccsds.org] On Behalf 
Of Moury Gilles
Sent: Friday, March 31, 2017 2:00 AM
To: Daniel.Fischer at esa.int; sls-sea-dls at mailman.ccsds.org
Subject: Re: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard 
  
Dear all, 
  
My response to David?s questions would be : 
  
Q1 : values 0 and 65535 are reserved (for master keys I understand). Text 
should be modified. 
  
Q2 : EP baseline mode relies on SDLS baseline mode. SDLS baseline mode 
uses AES-GCM. In that case, the SN is replaced by the IV which is 96 bits. 
Therefore, the Set ARC procedure of the EP baseline mode is actually 
setting the IV. I would recommend adding this clarification in the EP 
baseline mode specification and changing the length of the ?New 
anti-replay counter value? field from 64 to 96 bits for consistency with 
SDLS baseline mode. 
  
Q3 : My proposal would be the following: 
·        For the EP baseline mode, a format is specified for the 
GVCID/GMAPID field of the  Start SA PDU with the following sub-fields: 
o   TFVN (4 bits) 
o   SCID (16 bits) 
o   VCID (6 bits) 
o   MAPID (6bits) 
·        Since we have specified TFVN sub-field length as 4 bits, we have 
2 spare bits there. We could use one of them to distinguish TC from TM : 
?000? would code for TC TFVN and ?100? would code for TM TFVN, while ?001? 
would code for AOS and ?010? for Prox-1 (which is not covered by SDLS by 
the way). 
  
Best regards, 
Gilles 
  
  
  
Gilles MOURY 
CNES Toulouse 
De : SLS-SEA-DLS [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part 
de Daniel.Fischer at esa.int
Envoyé : vendredi 31 mars 2017 08:57
À : sls-sea-dls at mailman.ccsds.org
Objet : [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard 
  
Dear all, 

Could ask you to take a look at the questions that David sent a while 
go...some of them need answers before a red book can be produced. 
My take: 
Q1 is a typo and will be corrected. --> No further discussion needed 
Q2: This should be the case. What do the others think? Do we need to be 
explicit there? 
Q3: This is a critical one and we don't have an answer at the moment. I 
remember we discussed this in the WG already but I am not sure we came to 
a conclusion. This needs to be clarified in the standard. Any opinions? 

Cheers,
Daniel. 

Dr. Daniel Fischer
Head of the Engineering Support Section, OPS-GES
Ground Systems Engineering Department 
Directorate of Operations 
ESA - ESOC
Robert-Bosch-Str. 5, D-64392 Darmstadt, Germany 
Tel. +49 6151 90 2718 |  E-mail: Daniel.Fischer at esa.int 
----- Forwarded by Daniel Fischer/esoc/ESA on 31/03/2017 08:51 ----- 

From:        David.Koisser at esa.int 
To:        sls-sea-dls at mailman.ccsds.org 
Cc:        "John P. Lucas" <John.P.Lucas at ivv.nasa.gov> 
Date:        01/03/2017 11:04 
Subject:        [Sls-sea-dls] Question regarding the SDLS EP Standard 
Sent by:        "SLS-SEA-DLS" <sls-sea-dls-bounces at mailman.ccsds.org> 





Dear SDLS WG members, 

John and I have completed setting up the interoperability testing 
environment and now we are doing a few finishing touches. Whilst doing 
this a few questions arose regarding the SDLS EP standard: 

1. In Section E4.2.2 (in the baseline mode description of Key Activation) 
and the following key procedures, it defines the Key ID fields to have a 
length of 16 bits. And then states: 
"Values 0-65535 shall not be used to reference session keys." 
Which would be all possible Key IDs and leave none for any session keys. 
Can you clarify? 

2. While we are fairly sure it is implied: Does the M&C procedure Set ARC 
set the IV instead of the SN parameter in the regarding cases (e.g. 
AES-GCM)? 

3. The standard is not addressing how to distinguish if a GVCID is 
regarding the TM or TC channels for the Start SA procedure. An example to 
clarify: 

A mission wants a different SA assigned on VC 0 for the uplink (e.g. 
authentication only) than the VC 0 for the downlink (e.g. authenticated 
encryption). To be able to set this with the Start SA procedure, it needs 
a way to distinguish between the TC and TM channel mapping to SPIs. As the 
GVCID is defined as: 
GVCID = TFVN + SCID + VCID 
And the 2 bits long TFVN may have the following values: 01 -> AOS; 10 -> 
Proximity-1; 00 -> TM- *or* TC-SDLP 
The GVCID alone is not enough to distinguish between TC and TM and we are 
currently using a custom data structure for unambiguously identifying the 
channels in the Start SA procedure. 

Best Regards, 
David Koisser 
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.

_______________________________________________
SLS-SEA-DLS mailing list
SLS-SEA-DLS at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls




Disclaimer 
This message and any attachments are intended for the use of the addressee 
or addressees only. The unauthorized 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. 
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.



Disclaimer 
This message and any attachments are intended for the use of the addressee 
or addressees only. The unauthorized 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.




Disclaimer
This message and any attachments are intended for the use of the addressee 
or addressees only. The unauthorized 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.




Disclaimer
This message and any attachments are intended for the use of the addressee 
or addressees only. The unauthorized 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.
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/20170412/b830548a/attachment.html>


More information about the SLS-SEA-DLS mailing list