[Sls-sea-dls] Re: RE : RE : [Sls-slp] Security, NGU and New TC services and there effecton COP-1
Moury Gilles
gilles.moury at cnes.fr
Mon Oct 19 15:53:41 UTC 2009
CNES installed base is similar to NASA's :
- command frames built at SCC, together with COP and encryption/authentication. CLTU transferred from SCC to G/S using SLE-FCLTU service.
Other architecture can exist where TC frames building and FOP are handled in G/S, TC packets/segments being sent from the SCC to the G/S using SLE-FSP service. I do not know whether this scenario has been implemented by one agency ?
Best regards,
Gilles
Gilles MOURY
CNES Toulouse
-----Message d'origine-----
De : Greenberg, Edward (313B) [mailto:edward.greenberg at jpl.nasa.gov]
Envoyé : samedi 17 octobre 2009 15:32
À : Greenberg, Edward (313B); Moury Gilles; Marjorie de Lande Long Cc : SLS-SLP WG; Gian.Paolo.Calzolari; Matt at mail.jpl.nasa.gov; SDLS WG; Howie Weiss; Shames, Peter M (3130); Barkley, Erik J (317H) Objet : RE: [Sls-sea-dls] Re: RE : RE : [Sls-slp] Security, NGU and New TC services and there effecton COP-1
I think that we need to understand the installed base for commanding. Commanding with AOS has significantly different properties and approaches from commanding with TC, so maybe we can limit this discussion to TC. NASA's architecture has the command frames built at the project's operations center (POCC). Command sequences for instruments can be formulated by the experimenters and transferred to the POCC but commands are formulated into TC frames at the POCC. The POCC performs the COP and uses SLE-FCLTU service to deliver the CLTUs to the station for radiation. In this scenario the SDLS service is performed at the POCC before the COP and is transparent to the SLE service and the station. I can envision an architecture where the CLTUs are composed at the POCC with SDLS service performed at the POCC and the COP being provided by the station (this would require FCLTU SDUs to provide the COP with information pertaining to multiple transmissions of the same CLTU to accommodate ESA's most recent request for change in the COP). But the use of SLE packet service from the POCC to a central operations center or to the station would put all the TC formulation and COP control at that site where the SDLS service would need to be provided. The remote control of the SDLS service would then need to be integrated into service management and provisioning. So what is the architecture for ESA and CNES and other agencies? What installed base are we working with?
________________________________________
From: sls-sea-dls-bounces at mailman.ccsds.org [sls-sea-dls-bounces at mailman.ccsds.org] On Behalf Of Greenberg, Edward (313B) [edward.greenberg at jpl.nasa.gov]
Sent: Friday, October 16, 2009 1:05 PM
To: Gilles Moury; Marjorie de Lande Long
Cc: SLS-SLP WG; Gian.Paolo.Calzolari; Matt at mail.jpl.nasa.gov; SDLS WG; Howie Weiss; Shames, Peter M (3130)
Subject: [Sls-sea-dls] Re: RE : RE : [Sls-slp] Security, NGU and New TC services and there effecton COP-1
I'll take a little issue with Gilles, It all depends on where the frame/CLTU is crated. If the creation is in the POCC and sent vial FCLTU service than scenario one is totally compatible with every thing. (flight and ground). The TC Decoder is unaffected as is the COP. The security ia added befor the frame leaves the POCC and is process on the S/C before the frame is delivered to the TC Decoder.
On 10/16/09 10:52 AM, "Gilles Moury" <gilles.moury at cnes.fr> wrote:
Hello Marjorie,
With respect to the interaction between COP-1 and SDLS protocol in TC, there are 2 possible scenarios :
Scenario 1 :
Sending end : FOP then SDLS procedure
Receiving end : SDLS procedure then FARM
Scenario 2 :
Reverse order both at sending end and receiving end
Pros/Cons :
- scenario 1 :
Pros : DLS protocol protects all TC frames (AD, BD, BC). Especially BC frames are protected which is not negligible in terms of overall security of the TC link. Cons : SDLS control commands cannot benefit from AD service. If you handle FOP and transfer sub-layer at the ground station, you need to implement SDLS sending end at the ground station as well which can be a security problem (key protection).
- scenario 2 :
Pros : fully compatible with existing CCSDS TC decoder : SDLS processor (receiving end) can be plugged in at the output of existing TC decoders. Security errors (detected & reported by SDLS only) can be easily distinguished from channel errors (detected & reported by FARM only). SDLS specification easier to develop because SDLS protocol clearly separated from transfer sublayer (in between transfer sub-layer and segmentation sub-layer). SDLS control commands can benefit from AD service. Cons : SDLS protocol position in CCSDS stack different in TC (between segmentation and transfer sub-layers) and in TM/AOS (between transfer and coding sub-layers). Lower security (no security for BC frames).
Best regards,
Gilles
Gilles MOURY
CNES Toulouse
-----Message d'origine-----
De : sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] De la part de Marjorie de Lande Long Envoyé : vendredi 16 octobre 2009 19:12 À : Moury Gilles Cc : SLS-SLP WG; Gian.Paolo.Calzolari; Shames, Peter M (3130); Matt Cosby; Howie Weiss; Greenberg, Edward (313B) Objet : RE : [Sls-slp] Security, NGU and New TC services and there effecton COP-1
Hallo everyone,
I have been following this discussion with interest, about the position of the security checks w.r.t. the FARM at the receiving end.
> In short, your common conclusion is that there is no interaction
> between DLS protocol and COP-1 protocol which ever the order in which
> we process them. Am I correct ?
The position of the security at the sending end is another factor. I think there is some interaction with the FOP there:
1. The Cryptography Service draft says the ICV (Integrity Check Value) is computed over the whole frame except for the optional CRC. If that is correct, then it includes the Frame Primary Header, which has the Frame Sequence Number. For AD frames, the sequence number is provided by the FOP, so that should mean that the security is done after the FOP at the sending end. BC frames are created inside the FOP, and that also suggests that the security is done after the FOP. (Does the same security apply to BC frames?)
2. And if (1) is true, then symmetry at the receiving end would place the security checks before the FARM.
Best regards,
Marjorie
On Fri, 2009-10-16 at 16:43 +0200, Moury Gilles wrote:
> Good afternoon Ed and Matt,
>
> At our next SDLS WG meeting, we will have to decide where we insert
> the Data Link Security sublayer within the CCSDS Data Link Layer.
> Several options exist. If I understood well, what you agree on is that
> we can, for TC at the receiving end :
>
> - either perform security check before the FARM, in that case any AD
> frame rejected by security will be NACKed and retransmitted by COP
> - either perform security check after FARM, just before handling TC
> segment to the upper layer. In that case, upper layers will have to
> handle missing segments/packets (I assume DLS protocol will not
> include yet another retransmission protocol !).
>
> In short, your common conclusion is that there is no interaction
> between DLS protocol and COP-1 protocol which ever the order in which
> we process them. Am I correct ?
>
> Personally, I favour "security check before FARM" scenario since, as
> Ed states, it provides automatic retransmission of frames which did
> not pass security checks.
>
> Best regards,
> Gilles
>
>
> Gilles MOURY
> CNES Toulouse
>
>
> -----Message d'origine-----
> De : sls-slp-bounces at mailman.ccsds.org
> [mailto:sls-slp-bounces at mailman.ccsds.org] De la part de
> Greenberg, Edward (313B)
> Envoyé : jeudi 15 octobre 2009 18:23
> À : Howie Weiss; Matt Cosby
> Cc : Shames, Peter M (3130); SLS-SLP WG
> Objet : Re: [Sls-slp] Security, NGU and New TC services and
> there effecton COP-1
>
>
> As usual Howie you are correct....except there needs to be a
> process somewhere for the system on an end to end basis to
> report the failure at the security point or at the application
> layer. Are we going to invent a protocol to do that at the
> security layer;. notifying the remote user of the failure at
> the security check point? Cop-1 will respond to the loss of a
> frame and request a replacement. I guess we could relate you
> argument to TCP; its role is to handle link problems (ordering
> and loss) and security (using IPSec) is riding on top of
> that. If the system requires in order delivery of good data
> without loss then there needs to be a protocol at the
> application layer that requests the missed item. I don't
> believe that we want to do that.....so I'll continue to say
> that the COP is there to assure the delivery of in order
> without loss delivery.
>
>
> On 10/15/09 7:51 AM, "Howie Weiss" <Howard.Weiss at cobham.com>
> wrote:
>
> Where we disagree is that the COP isn't "broken" if
> you put the security afterwards and the security layer
> fails its checks. This comes back to where the
> COP/FARM has finished its job (to guarantee delivery
> of complete in sequence, error free commands). Our
> disagreement was that I believe that the COP has
> finished when it hands the command to the next process
> (whatever that is) - in this example it is the
> security layer. You believe that the COP has not
> completing its job correctly if the next process or
> processes throws the command away for another failure
> - in this case if the security has failed.
>
> This is analogous to IPSec being above the link and
> network (IP) layers. While IP does not guarantee
> in-order delivery it does (sort of) guarantee that the
> packet isn't clobbered (based on its weak checksum).
> But IP is supposed to simply hand-of what it thinks
> is a good packet to IPSec for security processing. IP
> washes its (virtual) hands of the packet and it
> becomes IPSec's responsibility to pass it up to the
> next layer as "good" to to send it to the bit-bucket
> because it didn't pass muster.
>
> Howie
>
> -----------------------
>
> Howard Weiss
> Technical Director
> SPARTA National Security Sector
> Cobham Analytic Solutions
> T: 443 430 8089
> F: 443 430 8238
> C: 410 261 1479
> howard.weiss at cobham.com
>
> SPARTA, Inc., dba Cobham Analytic Solutions, 7110
> Samuel Morse Dr., Columbia MD 21046 www.sparta.com
> <http://www.sparta.com/>
>
> Please consider the environment before printing this
> email
>
>
>
>
>
> _______________________________________________
> Sls-slp mailing list
> Sls-slp at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/sls-slp
_______________________________________________
Sls-slp mailing list
Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp
_______________________________________________
Sls-slp mailing list
Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp
More information about the SLS-SLP
mailing list