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

[Moury Gilles]

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 
		
		
		 
		 
		
		

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20091016/0c5acf48/attachment.html>