<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><DIV>Dear Greg, </DIV> <DIV> </DIV> <DIV>I will not be available on Friday. So, I would appreciate if we can cover </DIV> <DIV>some of my RIDs on Thursday:</DIV> <DIV>732x1r1.RID_ESA_GA-{2,5,6,8,10}<BR><BR><BR><BR>Regards,<BR><BR>Guray Acar<BR>Telecommunications System Engineer,<BR>TEC-ETC ESA/ESTEC<BR>Tel: ++31715653041</DIV><BR><BR><FONT color=#990099>-----"SLS-SLP" <sls-slp-bounces@mailman.ccsds.org> wrote: -----</FONT>  <DIV style="PADDING-LEFT: 5px"> <DIV style="PADDING-LEFT: 5px; BORDER-LEFT: black 2px solid; PADDING-RIGHT: 0px">To: "Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" <craig.biggerstaff@nasa.gov><BR>From: "Kazz, Greg J (312B)" <GREG.J.KAZZ@JPL.NASA.GOV><BR>Sent by: "SLS-SLP" <SLS-SLP-BOUNCES@MAILMAN.CCSDS.ORG><BR>Date: 10/17/2016 17:37<BR>Cc: "sls-slp@mailman.ccsds.org" <sls-slp@mailman.ccsds.org>, "sea-sec@mailman.ccsds.org" <sea-sec@mailman.ccsds.org><BR>Subject: Re: [Sls-slp] SDLS RIDS for RED-1 USLP<BR><BR><!--Notes ACF <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">--> <DIV style="COLOR: rgb(0,0,0)">Craig,</DIV> <DIV style="COLOR: rgb(0,0,0)"><BR></DIV> <DIV style="COLOR: rgb(0,0,0)">SLP WG will address the SDLS RIDs on this Thursday. But my initial impression is the following TBC.</DIV> <DIV style="COLOR: rgb(0,0,0)"><BR></DIV> <DIV style="COLOR: rgb(0,0,0)">Thanks!</DIV> <DIV style="COLOR: rgb(0,0,0)">Greg</DIV> <DIV style="COLOR: rgb(0,0,0)"><BR></DIV><SPAN id=OLK_SRC_BODY_SECTION style="COLOR: rgb(0,0,0)"> <DIV style="FONT-SIZE: 11pt; BORDER-TOP: #b5c4df 1pt solid; FONT-FAMILY: Calibri; BORDER-RIGHT: medium none; BORDER-BOTTOM: medium none; COLOR: black; PADDING-BOTTOM: 0in; TEXT-ALIGN: left; PADDING-TOP: 3pt; PADDING-LEFT: 0in; BORDER-LEFT: medium none; PADDING-RIGHT: 0in"><SPAN style="FONT-WEIGHT: bold">From: </SPAN>"Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP]" <<A href="mailto:craig.biggerstaff@nasa.gov">craig.biggerstaff@nasa.gov</A>><BR><SPAN style="FONT-WEIGHT: bold">Date: </SPAN>Monday, October 17, 2016 at 7:27 AM<BR><SPAN style="FONT-WEIGHT: bold">To: </SPAN>"Kazz, Greg J (313B)" <<A href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</A>><BR><SPAN style="FONT-WEIGHT: bold">Cc: </SPAN>"<A href="mailto:sea-sec@mailman.ccsds.org">sea-sec@mailman.ccsds.org</A>" <<A href="mailto:sea-sec@mailman.ccsds.org">sea-sec@mailman.ccsds.org</A>><BR><SPAN style="FONT-WEIGHT: bold">Subject: </SPAN><no subject><BR></DIV> <DIV><BR></DIV> <DIV dir=ltr> <DIV ocsi="0" fpstyle="1"> <DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma; COLOR: #000000; DIRECTION: ltr"> <DIV>Greg (and all SLP WG members),</DIV> <DIV><BR></DIV> <DIV>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:</DIV> <DIV><BR></DIV> <DIV>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. *<SPAN style="FONT-WEIGHT: bold">Excellent</SPAN>*</DIV> <DIV><BR></DIV> <DIV>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”. *<SPAN style="FONT-WEIGHT: bold"> Agreed</SPAN>*</DIV></DIV></DIV></DIV></SPAN><SPAN id=OLK_SRC_BODY_SECTION> <DIV dir=ltr> <DIV ocsi="0" fpstyle="1"> <DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma; DIRECTION: ltr"> <DIV style="COLOR: rgb(0,0,0)"><BR></DIV> <DIV>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? ** <B style="FONT-SIZE: 16px; FONT-FAMILY: 'Times New Roman', serif"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma, sans-serif">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 </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma, sans-serif">we will remove it from the Virtual Channel Multiplexing Function. **</SPAN></B></DIV> <DIV style="COLOR: rgb(0,0,0)"><BR></DIV> <DIV>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<SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma, sans-serif"> a mission can choose it FEC’s length. This we will fix **</SPAN></DIV> <DIV style="COLOR: rgb(0,0,0)"><BR></DIV> <DIV style="COLOR: rgb(0,0,0)">Best regards,</DIV> <DIV style="COLOR: rgb(0,0,0)"><BR></DIV> <DIV style="COLOR: rgb(0,0,0)"><BR></DIV> <DIV style="COLOR: rgb(0,0,0)"><BR></DIV> <DIV style="COLOR: rgb(0,0,0)">Craig Biggerstaff, on behalf of the Security WG<BR></DIV></DIV></DIV></DIV></SPAN> <DIV><FONT size=2 face="Default Monospace,Courier New,Courier,monospace">_______________________________________________<BR>SLS-SLP mailing list<BR>SLS-SLP@mailman.ccsds.org<BR><A href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp</A><BR></FONT></DIV></DIV></DIV> <DIV></DIV></font><PRE>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.
</PRE>