<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 20px; font-family: Calibri, sans-serif;">
<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-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<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"><style id="owaParaStyle" type="text/css"></style>
<div fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<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 fpstyle="1" ocsi="0">
<div style="direction: ltr; font-family: Tahoma; font-size: 10pt;">
<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-family: 'Times New Roman', serif; font-size: 16px;"><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-family: Tahoma, sans-serif; font-size: 10pt;"> 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>
</body>
</html>