[Sls-slp] SDLS RIDS for RED-1 USLP

[Kazz, Greg J (312B)]

Craig,

SLP WG will address the SDLS RIDs on this Thursday. But my initial impression is the following TBC.

Thanks!
Greg

From: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>
Date: Monday, October 17, 2016 at 7:27 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "sea-sec at mailman.ccsds.org<mailto:sea-sec at mailman.ccsds.org>" <sea-sec at mailman.ccsds.org<mailto:sea-sec at mailman.ccsds.org>>
Subject: <no subject>

Greg (and all SLP WG members),

Since the USLP Red-1 review completed before the Security WG could discuss it, we reviewed USLP today in order to provide comments this week to SLP WG for discussion.  We noted several things:

0.  Overall, very good incorporation of SDLS.  For the most part, the Red-1 draft confirmed our earlier understanding of the interactions between USLP and SDLS. *Excellent*

1. In section 6.4.4.2, it says the Security Header and Trailer "shall be kept empty".  We believe this requirement applies only to the Virtual Channel Generation function, but it is ambiguously worded and could be misunderstood.  We recommend clarification:  e.g. as in 4.2.6.7, "...shall be kept empty by the Virtual Channel Generation Function”. * Agreed*

2. In section 6.4.1, it says SDLS may interface with USLP at either the Virtual Channel Generation Function (4.2.6) or the Virtual Channel Multiplexing Function (4.2.7).  We questioned why USLP provides both options.  If the intent is that SDLS be able to secure multiple data streams under a single Security Association, it seems that the capability to use SDLS with multiple VCs duplicates the use of SDLS to secure multiple MAPs within a single VC.  Is there another rationale? ** That was exactly the rationale.  Since we believed that SDLS allowed the multi-VC capability we included it in USLP.  However, if SDLS agrees we should take it out,  then we will remove it from the Virtual Channel Multiplexing Function. **

3. In section 4.1.6.1.3, the Frame Error Control Field allows for either CRC16 and CRC32.  We observed that using CRC16 with very large USLP frames will result in frequent SDLS authentication failures.  In addition, the Frame ECF is specified in 4.1.1 as only 2 octets, but later it is specified as either 2 or 4 octets. ** It should say that either 2 or 4 octet CRC is possible and a mission can choose it FEC’s length. This we will fix **

Best regards,



Craig Biggerstaff, on behalf of the Security WG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20161017/f197fa11/attachment.html>