[Sls-slp] FW: Selecting a date for "SDLS-COP interaction" telecon
Kazz, Greg J (313B)
greg.j.kazz at jpl.nasa.gov
Fri Jan 18 20:45:24 UTC 2013
Dear SLP,
Please see the time for the SDLS-COP interaction telecon below. I hope you
will participate. I will forward the details of how to join the telecon
once I receive them.
Best regards,
Greg Kazz
Chairman SLS-SLP WG
On 1/18/13 11:07 AM, "Moury Gilles" <Gilles.Moury at cnes.fr> wrote:
>Dear Greg and SDLS WG member,
>
>Given the responses I had to my poll for the date, I propose we hold our
>telecon on "SDLS-COP interaction" on Thursday February 21st, 16:00-19:00
>CET. Ignacio : could you please arrange the telecon from ESA ? (our
>telecon system at CNES is definitely not user friendly for non french
>natives !!!).
>
>Best regards and have a good week-end,
>
>Gilles
>
>Gilles MOURY
>CNES Toulouse
>-----Message d'origine-----
>De : Moury Gilles
>Envoyé : lundi 14 janvier 2013 19:09
>À : sls-sea-dls at mailman.ccsds.org; Greg J. Kazz
>Objet : Selecting a date for "SDLS-COP interaction" telecon
>
>Dear Greg and SDLS WG member,
>
>While updating the SDLS and TC Space Data Link books, questions about
>communication and security errors handling and reporting emerged (see
>attached mails from Ignacio). In particular interaction between COP (TC
>retransmission protocol) and SDLS needs to be sorted out and eventually
>specified in an update of the COP book. I propose to hold a telecon on
>the subject in the Feb/march timeframe before our next meeting in
>Bordeaux so we can finalize our proposal for COP update in Bordeaux.
>
>I propose the following dates :
>
>-February :
>
>- 21
>- 25
>- 26
>- 27
>- 28
>
>- March :
>
>- 1
>- 4
>- 5
>- 6
>- 7
>- 8
>
>Could you please indicate your availability, so I can select the optimal
>date. Telecon would start at 16:00 CET for 2-3 hours.
>
>Best regards,
>
>Gilles
>
>Gilles MOURY
>CNES Toulouse
>
>-----Message d'origine-----
>De : Moury Gilles
>Envoyé : lundi 14 janvier 2013 18:49
>À : 'Ignacio.Aguilar.Sanchez at esa.int'
>Cc : sls-sea-dls at mailman.ccsds.org; Greg J. Kazz
>Objet : RE: [Sls-sea-dls] SDLS Security Failure Report
>
>Dear Ignacio,
>
>Happy new year to you and all SDLS WG members. I hope 2013 will be the
>publication year of our long awaited SDLS blue book !
>
>I will circulate a Doodle poll to set up the telecon on "SDLS-COP
>interaction" in February.
>
>In the mean time, are we likely to start our combined agency reviews for
>SDLS and SDLP books as planned in Cleveland ? What is the status of the
>coordinated update of the SDLS book and of the SDLP books ?
>
>Best regards,
>
>Gilles
>
>Gilles MOURY
>CNES Toulouse
>
>-----Message d'origine-----
>De : Ignacio.Aguilar.Sanchez at esa.int
>[mailto:Ignacio.Aguilar.Sanchez at esa.int]
>Envoyé : mardi 8 janvier 2013 11:30
>À : Moury Gilles
>Cc : sls-sea-dls at mailman.ccsds.org
>Objet : RE: [Sls-sea-dls] SDLS Security Failure Report
>
>Dear Gilles,
>
>First of all happy new year to you and all CCSDS colleagues in copy!
>
>Sorry to come back now with my answer. I was on leave during that week,
>was
>back to my office yesterday and still catching up with past e-mail and
>actions.
>
>I think holding a telecon before the meeting is a good move. We need to
>explore the territory a bit before we plunge into more detail. I would
>expect
>we will need to go further during the Spring meeting.
>
>Concerning relevant experience I need to investigate a bit. In my view the
>closest thing to what we do in SDLS will be flown with the GMES Sentinels
>1,
>2 and 3. Furthermore, there is another project that also has security and
>is
>already flying. However, it is not as close to SDLS as the solution
>implemented in the GMES Sentinels. Still, I will investigate it.
>
>Concerning proposals I would rather wait to first understand well which
>are
>the issues we have to worry about.
>
>Let's organise this telecon. I would propose to hold it in February so
>that
>we can prepare a bit beforehand.
>
>Kind regards,
>
>Ignacio
>
>
>|------------>
>| From: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
> |Moury Gilles <Gilles.Moury at cnes.fr>
>
> |
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>|------------>
>| To: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
> |"Ignacio.Aguilar.Sanchez at esa.int" <Ignacio.Aguilar.Sanchez at esa.int>
>
> |
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>|------------>
>| Cc: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
> |"sls-sea-dls at mailman.ccsds.org" <sls-sea-dls at mailman.ccsds.org>
>
> |
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>|------------>
>| Date: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
> |17/12/2012 15:19
>
> |
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>|------------>
>| Subject: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
> |RE: [Sls-sea-dls] SDLS Security Failure Report
>
> |
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>|------------>
>| Sent by: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
> |sls-sea-dls-bounces at mailman.ccsds.org
>
> |
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
>
>
>
>
>Dear Ignacio,
>
>OK to organize before next meeting a telecon on interaction of SDLS with
>COP.
>For the time being, we update the 3 SDLP books (AOS, TC and TM) only
>adding
>section 6 (SDLP with SDLS option). The need to update COP blue book with
>an
>"SDLS option" section will be decided during the proposed telecon. I agree
>with you Ignacio that there are many implications behind the various
>possible
>interactions. Do you have on ESA side any experience/proposal you could
>share
>with the SDLS and SLP WGs ?
>
>Best regards,
>
>Gilles
>
>Gilles MOURY
>CNES Toulouse
>-----Message d'origine-----
>De : Ignacio.Aguilar.Sanchez at esa.int
>[mailto:Ignacio.Aguilar.Sanchez at esa.int]
>
>Envoyé : vendredi 14 décembre 2012 08:54
>À : Moury Gilles
>Cc : Greenberg, Edward (313B); sls-sea-dls at mailman.ccsds.org
>Objet : RE: [Sls-sea-dls] SDLS Security Failure Report
>
>Dear Gilles,
>
>I think this is a topic that deserves detailed analysis and discussion.
>Interfacing the COP machinery may have pros and cons.
>
>I am of the opinion that in order to differentiate the source of errors
>for a
>TC failed frame, it would better to keep separate the reporting and
>actions
>concerning communications and security failures.
>Reporting an authentication failure with an additional flag (instead of
>the
>logical OR of the two reasons for failure implied in your response) in the
>CLCW could a priori be useful.
>However, automatic re-transmission of a TC frame that failed
>authentication
>verification does not seem to me a good idea.
>
>But I think there is an issue concerning the interaction of the two
>protocols
>that needs to be addressed in detail, in particular when security fails
>and
>the channel does not. Just an example: should the FOP stop if it 'sees' a
>failed authentication reported? Should the FOP see this report in the
>first
>place? I assumed it should since a priori it does not seem to make sense
>to
>me to keep pushing TC frames up when the on-board channel appears to be
>blocked by the authentication function. Someone somehow should understand
>what's happening before keeping pushing frames.
>
>My recommendation: let's not rush into solving this question. Subject for
>a
>detailed problem definition and analysis with proposals to be discussed
>maybe
>in a dedicated telecon or in Spring meeting together with SLP.
>
>Kind regards,
>
>Ignacio
>
>
>|------------>
>| From: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
> |Moury Gilles <Gilles.Moury at cnes.fr>
>|
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
>|------------>
>| To: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
> |"Greenberg, Edward (313B)" <edward.greenberg at jpl.nasa.gov>
>|
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
>|------------>
>| Cc: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
> |"sls-sea-dls at mailman.ccsds.org" <sls-sea-dls at mailman.ccsds.org>
>|
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
>|------------>
>| Date: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
> |13/12/2012 19:56
>|
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
>|------------>
>| Subject: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
> |RE: [Sls-sea-dls] SDLS Security Failure Report
>|
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
>|------------>
>| Sent by: |
>|------------>
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
> |sls-sea-dls-bounces at mailman.ccsds.org
>|
>
>>-------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>----|
>
>
>
>
>
>
>Ed,
>
>SDLS is now a function called by SDLP (AOS, TC or TM). If a transfer
>frame
>is rejected by SDLS receiver, SDLS will return to calling SDLP a flag
>indicating the reason for rejection : Œsequence number mismatch¹, ŒMAC
>mismatch¹, Œinvalid SPI¹. For TC, TC SDLP receiver will transmit this
>'frame
>rejected' information to COP FARM. For the COP FARM, whether a frame is
>rejected because of "channel decoding" failure or "security check" failure
>makes no difference : COP FARM has to report a rejected/missing frame in
>CLCW
>to trigger retransmission form the ground by TC FOP. At the receiving end,
>COP FARM is called by TC SDLP after SDLS, so COP FARM will indifferently
>take
>into account rejected frames whether for uncorrectable channel errors or
>security errors.
>
>Best regards,
>
>Gilles
>
>Gilles MOURY
>CNES Toulouse
>-----Message d'origine-----
>De : Greenberg, Edward (313B) [mailto:edward.greenberg at jpl.nasa.gov]
>Envoyé : mercredi 5 décembre 2012 15:19
>À : Moury Gilles
>Objet : RE: [Sls-sea-dls] SDLS Security Failure Report
>
>I have a simple question. Should there be a flag for the COP If the
>frame is
>rejected by security after it was accepted by the COP.
>
>-----Original Message-----
>From: sls-sea-dls-bounces at mailman.ccsds.org [
>mailto:sls-sea-dls-bounces at mailman.ccsds.org] On Behalf Of Moury Gilles
>Sent: Wednesday, December 05, 2012 6:12 AM
>To: sls-sea-dls at mailman.ccsds.org
>Subject: [Sls-sea-dls] SDLS Security Failure Report
>
>-----Message d'origine-----
>De : Moury Gilles
>Envoyé : mercredi 5 décembre 2012 15:09
>À : 'Ignacio.Aguilar.Sanchez at esa.int'; sls-sea-dls@ Cc :
>marjorie at delandelong.com Objet : RE: [Sls-sea-dls] SDLS Security Failure
>Report
>
>Dear Ignacio,
>
>I am in line with your proposals for the 4 questions.
>
>For the "invalid SPI' failure case : we think we need it because the SDLS
>receiver will need to know which SA to use to perform its function. If it
>reads an invalid SPI in the security header, it will not be able to
>perform
>any security checks at all. So we need to distinguish this 'invalid SPI'
>failure case upfront and inform the user. SPI can be invalid for at least
>3
>reasons :
>
>- uninstantiated SPI (no SA associated)
>- associated SA not active
>- associated SA active but not valid for the VC used
>
>Does it clarify the interest of this failure case ?
>
>Best regards,
>Gilles
>
>Gilles MOURY
>CNES Toulouse
>
>-----Message d'origine-----
>De : sls-sea-dls-bounces at mailman.ccsds.org [
>mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de
>Ignacio.Aguilar.Sanchez at esa.int Envoyé : mercredi 5 décembre 2012 14:14 À
>:
>sls-sea-dls@ Cc : marjorie at delandelong.com Objet : [Sls-sea-dls] SDLS
>Security Failure Report
>
>
>Dear CCSDS SDLS colleagues,
>
>Following recent exchanges within the WG on two key SDLS issues raised by
>ESA, I would like to follow up on the second issue: the report in case of
>failure.
>
>As you know Gilles and Bruno provided valuable input on the four questions
>initially asked (see their e-mail from 28/11/2012).
>Last week as part of an ESA internal discussion we tackled the issue
>again.
>We concluded on the following:
>
>- Which kind of failure?
>As per current Red Book Œsequence number mismatch¹ and ŒMAC mismatch¹.
>We need clarification on the proposed Œinvalid SPI¹ by Gilles & Bruno. We
>are
>not sure about the interest of such report.
>
>- Which kind of report?
>Flags required to signal success or failure and cause; right now at least
>two
>flags.
>
>- Destination of the report?
>Report to SDLP calling function. SDL protocol to inform user at the
>receiving
>end.
>Further propagation of this report (e.g. TC application) should not be
>covered in the current versions of the SDLS and corresponding SDLPs.
>As part of the CCSDS SDLS work on Extended Procedures the WG would
>complete
>the analysis of this point. Such approach will allow to Œclose¹ both the
>SDLS
>and SDLPs now and postpone further impacts when the Extended Procedures
>have
>concluded their work.
>
>- Action as a result of the report?
>SDLPs shall discard the Œfailed¹ frames. As per SDLS Red Book, failed
>frames
>in TM could be delivered for forensics.
>Similarly as per previous question, further action should not be covered
>in
>the current versions of the SDLS and corresponding SDLPs.
>As part of the CCSDS SDLS work on Extended Procedures the WG would
>complete
>the analysis of this point. Such approach will allow to Œclose¹ both the
>SDLS
>and SDLPs now and postpone further impacts when the Extended Procedures
>have
>concluded their work.
>
>Let us know whether the above is agreeable.
>
>Greg: feel free to provide feedback.
>
>Kind regards,
>
>Ignacio
>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
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls
>
>
>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
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls
>
>
>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.
>
More information about the SLS-SLP
mailing list