[Sls-slp] Security, NGU and New TC services and there effecton COP-1
Greenberg, Edward (313B)
edward.greenberg at jpl.nasa.gov
Fri Oct 16 18:35:31 UTC 2009
See red below. Plus I have attached a slide showing how/where the security fits in various frames.
Note that security can be in the insert zone or with a secondary header in the secondary header data unit. For links where the security is on every frame the insert zone is preferred.
On 10/16/09 10:11 AM, "Marjorie de Lande Long" <marjorie at delandelong.com> wrote:
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 ? Here there is a slight disagreement. If the security is done before the FARM then the COP will request frames that fail the security and work "normally". If the secuity is after the COP and the frame passes the COP but fails the security then a gap in the accepted frame stream will occur and the delivered data after the security is error free but has a gap in continuity.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20091016/c9af802c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: link security in Frames.ppt
Type: application/x-mspowerpoint
Size: 226304 bytes
Desc: link security in Frames.ppt
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20091016/c9af802c/attachment.bin>
More information about the SLS-SLP
mailing list