80 likes | 254 Views
Space Data Link Security (SDLS) protocol. Discussion of remaining technical issues Portsmouth, May 6-7, 2010. Position of SDLS protocol in Space Data Link protocol stack. for TC space data link stack :. Position of SDLS protocol in Space Data Link protocol stack.
E N D
Space Data Link Security (SDLS) protocol Discussion of remaining technical issues Portsmouth, May 6-7, 2010
Position of SDLS protocol in Space Data Link protocol stack • for TC space data link stack : pied de page
Position of SDLS protocol in Space Data Link protocol stack • for TM space data link stack : pied de page
Position of SDLS protocol in Space Data Link protocol stack • for AOS space data link stack : pied de page
Selection of SDU to be authenticated • Full transfer frame (apart from ECF and MAC) : • pro’s : • slightly improved integrity check of TF header & OCF (wrt ECF) • In TC : sequence preserving service still possible because SDLS authentication & integrity check performed before FARM • con’s : • different SDU for authentication (full frame) and encryption (frame data field) • SDLS protocol splitted in two sub-functions inserted at different positions in SDL protocol stack, more complex in terms of specification (4 service interfaces to specify instead of two) • Reporting of security fails • Transfer frames data field : • pro’s : • protocol simpler to specify and more modular to implement • security function can be inserted as a plug-in in existing implementation (e.g. : ESA packet TC decoder) • con’s : • no sequence preserving service possible in TC (TC frames can be discarded by SDLS protocol after validation by COP/FARM) pied de page
Security objectives for authentication • general objectives : • integrity check • authentication of sender • enable anti-replay protection • trade-off for TC : • For unintentional errors : • already provided at frame level by BCH and frame CRC, but with lower performance than MAC • For intentional errors : • in no authentication of frame header : • possible attack on COP by sending BC frames (if BC frames are not protected for operational reasons), • will prevent sharing same Security Association on several VC, because VC switching will not be protected and several VC could use the same Security Context • Conclusion : protect frame header to protect VC switching pied de page
Security objectives for authentication • trade-off for TM and AOS : • for unintentional errors : • already provided at frame level by RS (if used) and frame CRC, but with lower performance than MAC • For intentional errors : • in no authentication of frame header : • will prevent sharing same Security Association on several VC, because VC switching will not be protected and several VC could use the same Security Context • Conclusion : protect the frame header (+ sec header + insert ) by authentication • Note : • Potential concern with layering violation : if complete TF header is authenticated, authentication function would have to analyze frame to extract VCID and select correct SA. Potential solution : not authentication master frame count. pied de page