[Sls-slp] Security, NGU and New TC services and there effecton COP-1

Marjorie de Lande Long marjorie at delandelong.com
Fri Oct 16 17:11:47 UTC 2009

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,

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

More information about the SLS-SLP mailing list