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

[Greenberg, Edward (313B)]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20091015/3e181d32/attachment.html>