From Gilles.Moury at cnes.fr Fri Apr 7 14:36:25 2017 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 7 Apr 2017 14:36:25 +0000 Subject: [Sls-sea-dls] TR: Spring 2017 Technical Meetings - San Antonio, United States - Registration Now Open In-Reply-To: References: Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A68613D@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear SDLS WG members, Registration is now open for the Spring 2017 CCSDS meetings in San Antonio TX at Southwest Research Institute (SWRI). Looking forward to a fruitful meeting, Best regards, Gilles MOURY CNES Toulouse De : CCSDS-All [mailto:ccsds-all-bounces at mailman.ccsds.org] De la part de The CCSDS-All mailing list is used by the CCSDS Secretariat to send out meeting and press releases related announcements. Envoyé : vendredi 7 avril 2017 15:24 À : ccsds-all at mailman.ccsds.org Cc : secretariat at mailman.ccsds.org Objet : [Ccsds-all] Spring 2017 Technical Meetings - San Antonio, United States - Registration Now Open Spring 2017 TECHNICAL PLENARY MEETING Hosted by NASA, the CCSDS Spring 2017 meeting series will be held at Southwest Research Institute in San Antonio, United States. The main technical meeting series will be held 8-12 May 2017. The CESG Meeting will be held on 15 May 2017 in San Antonio as well. The Spring CMC Meetings will be held on 13-16 June 2017 in St. Petersburg, Russia, hosted by ROSCOSMOS. For details and to register, visit https://cwe.ccsds.org/fm/Lists/2017SpringReg/newform.aspx Maps, hotel and other information are available at https://public.ccsds.org/meetings/2017Spring/default.aspx. IMPORTANT: Please note the following instructions and process: 1) All Users must have a CWE login. If not, then you must request one: http://cwe.ccsds.org/ReqLogin.aspx Several of the links in this e-mail will prompt you for your CWE Login. 2) All Users must have a profile in order to even SEE/VIEW the "Register for the Spring 2017 Meetings" button. If you have not created a profile but have a CWE login, then you will be notified that you cannot register until you have filled out your profile. 3) After your meeting registration is submitted you will receive a confirmation e-mail, like in previous registrations, and you will also receive a URL which allows you to edit your registration. Registration will close on 1 May 2017, one week before the start of the technical meetings to provide sufficient time for final logistics planning at SWRI. All attendees that require a Letter of Invitation for visa purposes should already have their letter. However, If you do not have a letter, please contact the Secretariat (Secretariat at mailman.ccsds.org) immediately so it can be arranged. Also, as always, dress for the Technical Plenary meeting is Business Casual. We look forward to seeing you in San Antonio, United States. Fall 2017 TECHNICAL PLENARY MEETING The Fall 2017 technical plenary will be hosted by ESA in The Hague, Netherlands. The technical meetings will be held from 6 - 9 November 2017 [Note: This will be a 4-day technical meeting]. The CESG Executive Committee will meet on Friday, 10 November 2017 in Noordwijk, Netherlands. The CMC will meet separately on 13-15 November 2017 in Darmstadt, Germany, hosted by ESA. Some preliminary information will be available after the Spring meetings. If you need a visa letter to attend the Fall 2017 meeting, please inform the Secretariat (Secretariat at mailman.ccsds.org), or indicate this when registering online, so that we can bring one to you in San Antonio or email it to you. CCSDS MEMBERSHIP, PARTICIPATION, IMPLEMENTATIONS Here are some reminders that are important whether or not you or your organization is going to attend a CCSDS meeting. If you are from a government agency that is not yet a CCSDS Observer Agency, you should consider getting your organization registered as a CCSDS Observer. Information is here: http://public.ccsds.org/participation/observer_agencies.aspx If you are from a private industry or academic organization that is involved (or interested) in CCSDS, but is not yet an Associate, you should consider registering your organization as a CCSDS Associate. Information is here: http://public.ccsds.org/participation/associates.aspx If your team is looking for software implementations that are publicly available, you should visit this page: http://public.ccsds.org/implementations/software.aspx If your team has developed software implementations that are publicly available, you should notify the Secretariat with info to post it on that same page: http://public.ccsds.org/implementations/software.aspx If your team has CCSDS implementations commercially available, you can have information about it posted on the CCSDS website, here: https://public.ccsds.org/implementations/products/default.aspx If you are explaining CCSDS to your organization, there are overview resources available here: https://public.ccsds.org/outreach/overview.aspx If you have any questions or comments, please email secretariat at mailman.ccsds.org We look forward to seeing you in San Antonio. Best regards, Michael Blackwood ASRC Federal Technical Services CCSDS Secretariat ________________________________ The preceding message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2512, is intended only for the person or entity to which it is addressed, and may contain information that is confidential, protected by attorney-client or other privilege, or otherwise protected from disclosure by law. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error and destroy the original message and all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From Gilles.Moury at cnes.fr Fri Apr 7 17:04:54 2017 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 7 Apr 2017 17:04:54 +0000 Subject: [Sls-sea-dls] CCSDS Space Data Link Security WG mailing list: reconfirmation of interest Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A686364@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear CCSDS SDLS WG mailing list member, You have subscribed to the CCSDS Space Data Link Security mailing list. We need to periodically reconfirm that our list are addressing interested parties. Therefore, could you please indicate: - Whether you wish to remain in this list - Your motivation for subscribing to the list - Your organization (and if applicable your sponsoring CCSDS space agency) Best regards, Gilles MOURY CCSDS SDLS WG Chairman -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Mon Apr 10 23:36:14 2017 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (312B)) Date: Mon, 10 Apr 2017 23:36:14 +0000 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard References: <442F062EBF46F247A96B8A50EF3EB6F42A65DC60@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <4EF9F303214ADB458948F9AD7A608EB31D5E4C47@ap-embx-sp30.RES.AD.JPL> 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" > Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" > ________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Fischer at esa.int Tue Apr 11 10:32:12 2017 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Tue, 11 Apr 2017 12:32:12 +0200 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: <4361_1491867391_58EC16FF_4361_7861_1_4EF9F303214ADB458948F9AD7A608EB31D5E4C47@ap-embx-sp30.RES.AD.JPL> References: <442F062EBF46F247A96B8A50EF3EB6F42A65DC60@TW-MBX-P04.cnesnet.ad.cnes.fr> <4361_1491867391_58EC16FF_4361_7861_1_4EF9F303214ADB458948F9AD7A608EB31D5E4C47@ap-embx-sp30.RES.AD.JPL> Message-ID: 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)" To: Moury Gilles , "Daniel.Fischer at esa.int" , "sls-sea-dls at mailman.ccsds.org" Cc: "Kazz, Greg J (312B)" 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" Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 11010 bytes Desc: S/MIME Cryptographic Signature URL: From Gilles.Moury at cnes.fr Tue Apr 11 11:08:02 2017 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Tue, 11 Apr 2017 11:08:02 +0000 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: References: <442F062EBF46F247A96B8A50EF3EB6F42A65DC60@TW-MBX-P04.cnesnet.ad.cnes.fr> <4361_1491867391_58EC16FF_4361_7861_1_4EF9F303214ADB458948F9AD7A608EB31D5E4C47@ap-embx-sp30.RES.AD.JPL> Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A68E597@TW-MBX-P03.cnesnet.ad.cnes.fr> 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)" > To: Moury Gilles >, "Daniel.Fischer at esa.int" >, "sls-sea-dls at mailman.ccsds.org" > Cc: "Kazz, Greg J (312B)" > 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" > Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" > _____ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Apr 11 16:37:02 2017 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Tue, 11 Apr 2017 16:37:02 +0000 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F42A68E597@TW-MBX-P03.cnesnet.ad.cnes.fr> References: <442F062EBF46F247A96B8A50EF3EB6F42A65DC60@TW-MBX-P04.cnesnet.ad.cnes.fr> <4361_1491867391_58EC16FF_4361_7861_1_4EF9F303214ADB458948F9AD7A608EB31D5E4C47@ap-embx-sp30.RES.AD.JPL> <442F062EBF46F247A96B8A50EF3EB6F42A68E597@TW-MBX-P03.cnesnet.ad.cnes.fr> Message-ID: <98C2F163-ABC2-426B-83DC-E5245AD8AE85@jpl.nasa.gov> 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 Date: Tuesday, April 11, 2017 at 4:08 AM To: "Daniel.Fischer at esa.int" , "Greenberg, Edward (312B)" Cc: Greg Kazz , "sls-sea-dls at mailman.ccsds.org" , Calzolari Gian-Paolo 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)" > To: Moury Gilles >, "Daniel.Fischer at esa.int" >, "sls-sea-dls at mailman.ccsds.org" > Cc: "Kazz, Greg J (312B)" > 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" > Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" > ________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gian.Paolo.Calzolari at esa.int Tue Apr 11 17:32:49 2017 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Tue, 11 Apr 2017 19:32:49 +0200 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: <98C2F163-ABC2-426B-83DC-E5245AD8AE85@jpl.nasa.gov> Message-ID: <2843_1491931971_58ED1343_2843_2283_1_OF24BAEEC4.C2BE4E9E-ONC12580FF.00606328-1491931968814@esa.int> 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) 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 > Date: Tuesday, April 11, 2017 at 4:08 AM > To: "Daniel.Fischer at esa.int" , "Greenberg, Edward (312B)" > Cc: Greg Kazz , "sls-sea-dls at mailman.ccsds.org" , Calzolari Gian-Paolo > 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)" > To: Moury Gilles , "Daniel.Fischer at esa.int" , "sls-sea-dls at mailman.ccsds.org" > Cc: "Kazz, Greg J (312B)" > 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" > Date: 01/03/2017 11:04 > Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard > Sent by: "SLS-SEA-DLS" > > > > > > 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. 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: From Daniel.Fischer at esa.int Wed Apr 12 05:15:52 2017 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Wed, 12 Apr 2017 07:15:52 +0200 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: References: <98C2F163-ABC2-426B-83DC-E5245AD8AE85@jpl.nasa.gov> Message-ID: 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)" Cc: "Moury Gilles" , Daniel Fischer/esoc/ESA at ESA, "Greenberg, Edward (312B)" , "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) 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 Date: Tuesday, April 11, 2017 at 4:08 AM To: "Daniel.Fischer at esa.int" , "Greenberg, Edward (312B)" Cc: Greg Kazz , "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)" To: Moury Gilles , "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)" 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" Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 11010 bytes Desc: S/MIME Cryptographic Signature URL: From Daniel.Fischer at esa.int Wed Apr 12 08:49:10 2017 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Wed, 12 Apr 2017 10:49:10 +0200 Subject: [Sls-sea-dls] SDLS Extended Prcocedures Red Book Draft 1.3 Message-ID: Dear all, I have finished the update of the SDLS Extended Procedures Draft Red Book. Please find it attached. Updates included: - Definition of managed parameters for Key Management - Definition of managed parameters for SU Management and Control - Inclusion of Key Management and SU Management and Control PDUs in the PICS - Completed Security Section - Updated Baseline Mode (DK comments, Inclusion of CRC definition provided by Gilles (D 4.3)) Please note: This is a HUGE document. I am pretty sure there are still a not of small problems in it. If you have some time, could you please check the document for things like this? I am afraid we are not ready for Red Book Status yet. In recent discussions on the mailing list and also with industry a number of questions popped up that need to be clarified first. 1) SA Management Discussion It was pointed out that the way how keys can be changed on a running SA may not be practicable. At the moment, this requires four SA procedures to be executed. (1) Stoop SA, (2) Expire SA (3) Rekey SA (4) Start SA. However, it may be preferable to be able to change the keys "on the fly" without having to shut down the SA. This would make key changing much simpler. 2) OTAR/Key Verification Procedures Discussion The rationale for us to introduce the CRC check was to be able to execute the Key Verification without having to start the lifetime of the key that is being checked. Industry however pointed out that (1) These kind of checks are usually done by the spacecraft anyway on its memory and (2) That a CRC is not secure and will not guarantee that keys cannot be modified onboard the spacecraft. Instead they suggested to go back to the old Challenge/Response concept but only execute that prior to activating the session key for operations anyway. In this way, the start of the key lifetime is not a problem. 3) Use of Master Keys We have specified which procedures are considered sensitive. Industry pointed out that it is still not clear which procedures requires protection under a master key (so far only the OTAR specifies that directly) and in general what the master keys are being used for. Some of this is in the Symmetric Key Management Book however we should think about if we want to have other procedures especially protected under the use of a master key. 4) Association of ARC to Key instead of SPI Industry suggested to associate the ARC to a key rather than an SPI. They argue that is is a more natural connection since a new key would also start a new ARC (TBD). I personally disagree with this but I think its worth discussing this in the group. 5) Frame Security Report Industry appreciates the concept but has argued that the inclusion of additional error sources (and thus more flags and reduced bits from SN) should be included such as (a) bad MAC, (b) invalid Key/SA state, (c) invalid frame length. For me this makes sense. 6) Unique Identification of Sender and Receiver VCs. David has raised the point once more that sender and receiver VCs can currently not be distinguished (since the GVCID is not unique for up and downlinks). A discussion with SLS should take place in the meeting to find a solution for this since it does not only touch the Extended Procedures. Small things to be approved by the WG: - There seems to be a possible misunderstanding regarding the reserved SPIs. Industry thought that it always has to be exactly the two reserved ones for EP and no more. We may want to add a clarification. - Discussion on the extend to which the security log is specified in the Extended procedures. Ed suggested the global definition of a GVCIDS and GVCIDR which I personally find a good solution. While this looks like a lot of discussion material, I think we will actually be able to finalise the discussions in the next meeting and then publish the Red Book afterwards. 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDLS Extended Procedures Red 1 v3_no track.docx Type: application/octet-stream Size: 1537666 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 11010 bytes Desc: S/MIME Cryptographic Signature URL: From Gian.Paolo.Calzolari at esa.int Wed Apr 12 09:04:15 2017 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 12 Apr 2017 11:04:15 +0200 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: References: <98C2F163-ABC2-426B-83DC-E5245AD8AE85@jpl.nasa.gov> Message-ID: <30156_1491987858_58EDED92_30156_272_1_OF54771A24.AC7155C9-ONC1258100.00316CE8-C1258100.0031D442@esa.int> 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)" , "Moury Gilles" , "Kazz, Greg J (312B)" , "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)" Cc: "Moury Gilles" , Daniel Fischer/esoc/ESA at ESA, "Greenberg, Edward (312B)" , "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) 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 Date: Tuesday, April 11, 2017 at 4:08 AM To: "Daniel.Fischer at esa.int" , "Greenberg, Edward (312B)" Cc: Greg Kazz , "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)" To: Moury Gilles , "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)" 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" Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" 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: From Gilles.Moury at cnes.fr Wed Apr 12 13:02:22 2017 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Wed, 12 Apr 2017 13:02:22 +0000 Subject: [Sls-sea-dls] SDLS Extended Prcocedures Red Book Draft 1.3 In-Reply-To: References: Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A695256@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear Daniel, Thank you for this updated and now complete version of the SDLS Extended Procedures draft red book. I will review the document and encourage WG members to do likewise so we can spot any coherency or editorial problem. I agree that it will be difficult to converge before the meeting by mail on all the remaining points you listed. Therefore, I will include in the agenda of the San Antonio meeting a point on the "finalization of SDLS EP red-1". To maximize our chances to effectively converge on a commonly agreed red-1 book at the end of the meeting, we should make sure we collect all the issues before the meeting. I will also include in the agenda a specific point on "GVCID and unambiguous identification of VCs in bidirectional links", this point to be discussed jointly with SLP WG. Best regards, Gilles Gilles MOURY SDLS WG Chair De : SLS-SEA-DLS [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Daniel.Fischer at esa.int Envoyé : mercredi 12 avril 2017 10:49 À : sls-sea-dls at mailman.ccsds.org Objet : [Sls-sea-dls] SDLS Extended Prcocedures Red Book Draft 1.3 Dear all, I have finished the update of the SDLS Extended Procedures Draft Red Book. Please find it attached. Updates included: - Definition of managed parameters for Key Management - Definition of managed parameters for SU Management and Control - Inclusion of Key Management and SU Management and Control PDUs in the PICS - Completed Security Section - Updated Baseline Mode (DK comments, Inclusion of CRC definition provided by Gilles (D 4.3)) Please note: This is a HUGE document. I am pretty sure there are still a not of small problems in it. If you have some time, could you please check the document for things like this? I am afraid we are not ready for Red Book Status yet. In recent discussions on the mailing list and also with industry a number of questions popped up that need to be clarified first. 1) SA Management Discussion It was pointed out that the way how keys can be changed on a running SA may not be practicable. At the moment, this requires four SA procedures to be executed. (1) Stoop SA, (2) Expire SA (3) Rekey SA (4) Start SA. However, it may be preferable to be able to change the keys "on the fly" without having to shut down the SA. This would make key changing much simpler. 2) OTAR/Key Verification Procedures Discussion The rationale for us to introduce the CRC check was to be able to execute the Key Verification without having to start the lifetime of the key that is being checked. Industry however pointed out that (1) These kind of checks are usually done by the spacecraft anyway on its memory and (2) That a CRC is not secure and will not guarantee that keys cannot be modified onboard the spacecraft. Instead they suggested to go back to the old Challenge/Response concept but only execute that prior to activating the session key for operations anyway. In this way, the start of the key lifetime is not a problem. 3) Use of Master Keys We have specified which procedures are considered sensitive. Industry pointed out that it is still not clear which procedures requires protection under a master key (so far only the OTAR specifies that directly) and in general what the master keys are being used for. Some of this is in the Symmetric Key Management Book however we should think about if we want to have other procedures especially protected under the use of a master key. 4) Association of ARC to Key instead of SPI Industry suggested to associate the ARC to a key rather than an SPI. They argue that is is a more natural connection since a new key would also start a new ARC (TBD). I personally disagree with this but I think its worth discussing this in the group. 5) Frame Security Report Industry appreciates the concept but has argued that the inclusion of additional error sources (and thus more flags and reduced bits from SN) should be included such as (a) bad MAC, (b) invalid Key/SA state, (c) invalid frame length. For me this makes sense. 6) Unique Identification of Sender and Receiver VCs. David has raised the point once more that sender and receiver VCs can currently not be distinguished (since the GVCID is not unique for up and downlinks). A discussion with SLS should take place in the meeting to find a solution for this since it does not only touch the Extended Procedures. Small things to be approved by the WG: - There seems to be a possible misunderstanding regarding the reserved SPIs. Industry thought that it always has to be exactly the two reserved ones for EP and no more. We may want to add a clarification. - Discussion on the extend to which the security log is specified in the Extended procedures. Ed suggested the global definition of a GVCIDS and GVCIDR which I personally find a good solution. While this looks like a lot of discussion material, I think we will actually be able to finalise the discussions in the next meeting and then publish the Red Book afterwards. 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Moury at cnes.fr Wed Apr 12 13:09:32 2017 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Wed, 12 Apr 2017 13:09:32 +0000 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: <2843_1491931971_58ED1343_2843_2283_1_OF24BAEEC4.C2BE4E9E-ONC12580FF.00606328-1491931968814@esa.int> References: <98C2F163-ABC2-426B-83DC-E5245AD8AE85@jpl.nasa.gov> <2843_1491931971_58ED1343_2843_2283_1_OF24BAEEC4.C2BE4E9E-ONC12580FF.00606328-1491931968814@esa.int> Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A6952B6@TW-MBX-P04.cnesnet.ad.cnes.fr> We could also schedule a 1H30 session on Thursday morning or afternoon when both SLP and SDLS WG meet. Gilles MOURY CNES Toulouse De : Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Envoyé : mardi 11 avril 2017 19:33 À : Kazz, Greg J (312B) Cc : Moury Gilles; Daniel.Fischer at esa.int; Greenberg, Edward (312B); sls-sea-dls at mailman.ccsds.org Objet : 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) > 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 > Date: Tuesday, April 11, 2017 at 4:08 AM To: "Daniel.Fischer at esa.int" >, "Greenberg, Edward (312B)" > Cc: Greg Kazz >, "sls-sea-dls at mailman.ccsds.org" >, Calzolari Gian-Paolo > 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)" > To: Moury Gilles >, "Daniel.Fischer at esa.int" >, "sls-sea-dls at mailman.ccsds.org" > Cc: "Kazz, Greg J (312B)" > 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" > Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" > ________________________________ 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. 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: From greg.j.kazz at jpl.nasa.gov Wed Apr 12 15:30:26 2017 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Wed, 12 Apr 2017 15:30:26 +0000 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F42A6952B6@TW-MBX-P04.cnesnet.ad.cnes.fr> References: <98C2F163-ABC2-426B-83DC-E5245AD8AE85@jpl.nasa.gov> <2843_1491931971_58ED1343_2843_2283_1_OF24BAEEC4.C2BE4E9E-ONC12580FF.00606328-1491931968814@esa.int> <442F062EBF46F247A96B8A50EF3EB6F42A6952B6@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: Gilles, Thursday at 13:30 (after the lunch) is good. SLP WG is meeting in a room next to the Cafeteria (Cafeteria 3 i.e., C-3) so I recommend the two groups meet there. I will add it to the SLP WG agenda. Regards, Greg From: Moury Gilles Date: Wednesday, April 12, 2017 at 6:09 AM To: "Gian.Paolo.Calzolari at esa.int" , Greg Kazz Cc: "Daniel.Fischer at esa.int" , "Greenberg, Edward (312B)" , "sls-sea-dls at mailman.ccsds.org" Subject: RE: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard We could also schedule a 1H30 session on Thursday morning or afternoon when both SLP and SDLS WG meet. Gilles MOURY CNES Toulouse De : Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Envoyé : mardi 11 avril 2017 19:33 À : Kazz, Greg J (312B) Cc : Moury Gilles; Daniel.Fischer at esa.int; Greenberg, Edward (312B); sls-sea-dls at mailman.ccsds.org Objet : 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) > 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 > Date: Tuesday, April 11, 2017 at 4:08 AM To: "Daniel.Fischer at esa.int" >, "Greenberg, Edward (312B)" > Cc: Greg Kazz >, "sls-sea-dls at mailman.ccsds.org" >, Calzolari Gian-Paolo > 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)" > To: Moury Gilles >, "Daniel.Fischer at esa.int" >, "sls-sea-dls at mailman.ccsds.org" > Cc: "Kazz, Greg J (312B)" > 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" > Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" > ________________________________ 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. 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: From Dorothea.Richter at dlr.de Thu Apr 13 13:31:16 2017 From: Dorothea.Richter at dlr.de (Dorothea.Richter at dlr.de) Date: Thu, 13 Apr 2017 13:31:16 +0000 Subject: [Sls-sea-dls] SDLS Extended Prcocedures Red Book Draft 1.3 In-Reply-To: References: Message-ID: Daniel et all, please find attached a version of the draft RB containing some comments from my side. Happy Easter and see you soon in San Antonio, Dorothea ________________________________ Von: SLS-SEA-DLS [sls-sea-dls-bounces at mailman.ccsds.org]" im Auftrag von "Daniel.Fischer at esa.int [Daniel.Fischer at esa.int] Gesendet: Mittwoch, 12. April 2017 10:49 An: sls-sea-dls at mailman.ccsds.org Betreff: [Sls-sea-dls] SDLS Extended Prcocedures Red Book Draft 1.3 Dear all, I have finished the update of the SDLS Extended Procedures Draft Red Book. Please find it attached. Updates included: - Definition of managed parameters for Key Management - Definition of managed parameters for SU Management and Control - Inclusion of Key Management and SU Management and Control PDUs in the PICS - Completed Security Section - Updated Baseline Mode (DK comments, Inclusion of CRC definition provided by Gilles (D 4.3)) Please note: This is a HUGE document. I am pretty sure there are still a not of small problems in it. If you have some time, could you please check the document for things like this? I am afraid we are not ready for Red Book Status yet. In recent discussions on the mailing list and also with industry a number of questions popped up that need to be clarified first. 1) SA Management Discussion It was pointed out that the way how keys can be changed on a running SA may not be practicable. At the moment, this requires four SA procedures to be executed. (1) Stoop SA, (2) Expire SA (3) Rekey SA (4) Start SA. However, it may be preferable to be able to change the keys "on the fly" without having to shut down the SA. This would make key changing much simpler. 2) OTAR/Key Verification Procedures Discussion The rationale for us to introduce the CRC check was to be able to execute the Key Verification without having to start the lifetime of the key that is being checked. Industry however pointed out that (1) These kind of checks are usually done by the spacecraft anyway on its memory and (2) That a CRC is not secure and will not guarantee that keys cannot be modified onboard the spacecraft. Instead they suggested to go back to the old Challenge/Response concept but only execute that prior to activating the session key for operations anyway. In this way, the start of the key lifetime is not a problem. 3) Use of Master Keys We have specified which procedures are considered sensitive. Industry pointed out that it is still not clear which procedures requires protection under a master key (so far only the OTAR specifies that directly) and in general what the master keys are being used for. Some of this is in the Symmetric Key Management Book however we should think about if we want to have other procedures especially protected under the use of a master key. 4) Association of ARC to Key instead of SPI Industry suggested to associate the ARC to a key rather than an SPI. They argue that is is a more natural connection since a new key would also start a new ARC (TBD). I personally disagree with this but I think its worth discussing this in the group. 5) Frame Security Report Industry appreciates the concept but has argued that the inclusion of additional error sources (and thus more flags and reduced bits from SN) should be included such as (a) bad MAC, (b) invalid Key/SA state, (c) invalid frame length. For me this makes sense. 6) Unique Identification of Sender and Receiver VCs. David has raised the point once more that sender and receiver VCs can currently not be distinguished (since the GVCID is not unique for up and downlinks). A discussion with SLS should take place in the meeting to find a solution for this since it does not only touch the Extended Procedures. Small things to be approved by the WG: - There seems to be a possible misunderstanding regarding the reserved SPIs. Industry thought that it always has to be exactly the two reserved ones for EP and no more. We may want to add a clarification. - Discussion on the extend to which the security log is specified in the Extended procedures. Ed suggested the global definition of a GVCIDS and GVCIDR which I personally find a good solution. While this looks like a lot of discussion material, I think we will actually be able to finalise the discussions in the next meeting and then publish the Red Book afterwards. 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDLS Extended Procedures Red 1 v3_no track_DR.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 1543541 bytes Desc: SDLS Extended Procedures Red 1 v3_no track_DR.docx URL: From Gilles.Moury at cnes.fr Tue Apr 18 09:40:56 2017 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Tue, 18 Apr 2017 09:40:56 +0000 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: References: <98C2F163-ABC2-426B-83DC-E5245AD8AE85@jpl.nasa.gov> <2843_1491931971_58ED1343_2843_2283_1_OF24BAEEC4.C2BE4E9E-ONC12580FF.00606328-1491931968814@esa.int> <442F062EBF46F247A96B8A50EF3EB6F42A6952B6@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A6A17B1@TW-MBX-P04.cnesnet.ad.cnes.fr> Greg, OK, I will insert this point in SDLS WG agenda. Regards, Gilles Gilles MOURY CNES Toulouse De : Kazz, Greg J (312B) [mailto:greg.j.kazz at jpl.nasa.gov] Envoyé : mercredi 12 avril 2017 17:30 À : Moury Gilles; Gian.Paolo.Calzolari at esa.int Cc : Daniel.Fischer at esa.int; Greenberg, Edward (312B); sls-sea-dls at mailman.ccsds.org Objet : Re: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard Gilles, Thursday at 13:30 (after the lunch) is good. SLP WG is meeting in a room next to the Cafeteria (Cafeteria 3 i.e., C-3) so I recommend the two groups meet there. I will add it to the SLP WG agenda. Regards, Greg From: Moury Gilles > Date: Wednesday, April 12, 2017 at 6:09 AM To: "Gian.Paolo.Calzolari at esa.int" >, Greg Kazz > Cc: "Daniel.Fischer at esa.int" >, "Greenberg, Edward (312B)" >, "sls-sea-dls at mailman.ccsds.org" > Subject: RE: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard We could also schedule a 1H30 session on Thursday morning or afternoon when both SLP and SDLS WG meet. Gilles MOURY CNES Toulouse De : Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Envoyé : mardi 11 avril 2017 19:33 À : Kazz, Greg J (312B) Cc : Moury Gilles; Daniel.Fischer at esa.int; Greenberg, Edward (312B); sls-sea-dls at mailman.ccsds.org Objet : 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) > 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 > Date: Tuesday, April 11, 2017 at 4:08 AM To: "Daniel.Fischer at esa.int" >, "Greenberg, Edward (312B)" > Cc: Greg Kazz >, "sls-sea-dls at mailman.ccsds.org" >, Calzolari Gian-Paolo > 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)" > To: Moury Gilles >, "Daniel.Fischer at esa.int" >, "sls-sea-dls at mailman.ccsds.org" > Cc: "Kazz, Greg J (312B)" > 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" > Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" > ________________________________ 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. 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: From Gilles.Moury at cnes.fr Tue Apr 18 16:54:38 2017 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Tue, 18 Apr 2017 16:54:38 +0000 Subject: [Sls-sea-dls] CCSDS SDLS WG meeting agenda Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A6A1BF5@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear SDLS WG members, Please find attached for comment the proposed agenda for our upcoming San Antonio meeting : Please take note that there is a potential (TBC) joint session with RFM WG on Monday morning to discuss future work in the field of physical layer security. Best regards, Gilles Gilles MOURY SDLS WG chairman. Gilles MOURY CNES Toulouse Expert senior "Plateforme Satellite" Sous-Direction "Architecture, Validation & Intégration" DSO/AVI - Bpi 1416 18, avenue Edouard Belin F-31401 TOULOUSE Cedex 9 http://www.cnes.fr tel : +33 (0)5 61 27 3790 fax : +33 (0)5 61 27 4099 sec : +33 (0)5 61 27 3882 mob : +33 (0)6 83 56 0485 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Space Data Link Security WG May 10-11 2017 meeting agenda v1.doc Type: application/msword Size: 55808 bytes Desc: Space Data Link Security WG May 10-11 2017 meeting agenda v1.doc URL: From Gilles.Moury at cnes.fr Fri Apr 21 15:39:25 2017 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 21 Apr 2017 15:39:25 +0000 Subject: [Sls-sea-dls] CCSDS Space Data Link Security WG mailing list: reconfirmation of interest In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F42A686364@TW-MBX-P04.cnesnet.ad.cnes.fr> References: <442F062EBF46F247A96B8A50EF3EB6F42A686364@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A6AF893@TW-MBX-P04.cnesnet.ad.cnes.fr> This is a last call for those who have not yet responded but want to remain on the CCSDS Space Data Link Security WG mailing list. Best regards Gilles Gilles MOURY CCSDS SDLS WG Chairman De : SLS-SEA-DLS [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Moury Gilles Envoyé : vendredi 7 avril 2017 19:05 À : sls-sea-dls at mailman.ccsds.org Objet : [Sls-sea-dls] CCSDS Space Data Link Security WG mailing list: reconfirmation of interest Dear CCSDS SDLS WG mailing list member, You have subscribed to the CCSDS Space Data Link Security mailing list. We need to periodically reconfirm that our list are addressing interested parties. Therefore, could you please indicate: · Whether you wish to remain in this list · Your motivation for subscribing to the list · Your organization (and if applicable your sponsoring CCSDS space agency) Best regards, Gilles MOURY CCSDS SDLS WG Chairman -------------- next part -------------- An HTML attachment was scrubbed... URL: