[CESG] CESG-P-2018-08-001 Approval to publish CCSDS 350.0-G-3, The Application of CCSDS Protocols to Secure Systems (Green Book, Issue 3)

CCSDS Secretariat thomas.gannett at tgannett.net
Mon Feb 18 22:38:57 UTC 2019


Dear CESG Members,

Conditions for approval of CCSDS 350.0-G-3, The 
Application of Security to CCSDS Protocols (Green 
Book, Issue 3, February 2019) have been disposed 
to the satisfaction of the AD(s) who voted to 
approve with conditions. The Secretariat will now 
proceed with CMC polling to authorize publication.


>From: "Weiss, Howard" <Howard.Weiss at parsons.com>
>To: Thomas Gannett <thomas.gannett at tgannett.net>
>Subject: Re: [Secretariat] Updated 350.0-G
>Date: Thu, 24 Jan 2019 15:52:03 +0000
>
>Tom
>
>
>I think the attached are what you need.  Scott 
>Burleigh and I had a protracted discussion but 
>he finally gave up in the attached email and said he was ok.
>
>
>regards
>
>
>howie
>
>
>
>
>----------
>Howard Weiss, CISSP
>
>PARSONS, Inc.
>7110 Samuel Morse Drive
>Columbia, MD 21046
>443-430-8089 (office)
>443-494-9087 (cell)
>443-430-8238 (fax)
>howard.weiss at parsons.com
>www.parsons.com
>
>Please consider the environment before printing this message
>
>----------
>From: Thomas Gannett <thomas.gannett at tgannett.net>
>Sent: Wednesday, January 23, 2019 2:58 PM
>To: Weiss, Howard; 'CCSDS Secretariat'
>Subject: RE: [Secretariat] Updated 350.0-G
>
>Howie: I need to show agreement by the ADs who 
>had conditions. If you have e-mail threads 
>demonstrating they agree that their conditions 
>have been satisfied, please forward them to me. ­Tom
>
>
>Logothete, L.L.C.
>thomas.gannett at tgannett.net
>+1 443 472 0805
>
>From: Secretariat 
>[mailto:secretariat-bounces at mailman.ccsds.org] On Behalf Of Weiss, Howard
>Sent: Wednesday, January 23, 2019 2:46 PM
>To: CCSDS Secretariat
>Cc: Weiss, Howard
>Subject: [Secretariat] Updated 350.0-G
>
>
>Tom, et al
>
>
>
>Attached is the updated version of the Security 
>Protocols GB (350.0-G) with revisions per the CESG review.
>
>
>
>regards
>
>
>
>howie
>
>
>
>
>----------
>Howard Weiss, CISSP
>
>PARSONS, Inc.
>7110 Samuel Morse Drive
>Columbia, MD 21046
>443-430-8089 (office)
>443-494-9087 (cell)
>443-430-8238 (fax)
>howard.weiss at parsons.com
>www.parsons.com
>
>Please consider the environment before printing this message
>
>NOTICE: This email message and all attachments 
>transmitted with it may contain privileged and 
>confidential information, and information that 
>is protected by, and proprietary to, Parsons 
>Corporation, and is intended solely for the use 
>of the addressee for the specific purpose set 
>forth in this communication. If the reader of 
>this message is not the intended recipient, you 
>are hereby notified that any reading, 
>dissemination, distribution, copying, or other 
>use of this message or its attachments is 
>strictly prohibited, and you should delete this 
>message and all copies and backups thereof. The 
>recipient may not further distribute or use any 
>of the information contained herein without the 
>express written authorization of the sender. If 
>you have received this message in error, or if 
>you have any questions regarding the use of the 
>proprietary information contained therein, 
>please contact the sender of this message 
>immediately, and the sender will provide you with further instructions.
>Received: from ALHUN12EXCH01.Parsons.com (10.62.8.71) by
>  ALHUN12EXCH01.Parsons.com (10.62.8.71) with Microsoft SMTP Server (TLS) id
>  15.0.1367.3 via Mailbox Transport; Sat, 27 Oct 2018 11:28:28 -0500
>Received: from TXDAL11EXCH01.Parsons.com (172.21.212.127) by
>  ALHUN12EXCH01.Parsons.com (10.62.8.71) with Microsoft SMTP Server (TLS) id
>  15.0.1367.3; Sat, 27 Oct 2018 11:15:15 -0500
>Received: from txdal11mx02.parsons.com (206.219.199.110) by
>  TXDAL11EXCH01.Parsons.com (172.21.212.127) with Microsoft SMTP Server (TLS)
>  id 15.0.1367.3 via Frontend Transport; Sat, 27 Oct 2018 11:15:17 -0500
>Received: from pps.filterd (txdal11mx02.parsons.com [127.0.0.1])
>         by txdal11mx02.parsons.com 
> (8.16.0.21/8.16.0.21) with SMTP id w9RG99ec014756
>         for <howard.weiss at parsons.com>; Sat, 27 Oct 2018 11:15:17 -0500
>Authentication-Results: parsons.com;
>         spf=pass smtp.mailfrom=mario.merri at esa.int;
>         dmarc=none
>Received: from esrutmmgwext.esa.int (esrutmmgwext.esa.int [131.176.154.65])
>         by txdal11mx02.parsons.com with ESMTP id 2ncju6a3yd-1
>         (version=TLSv1.2 
> cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
>         for <howard.weiss at parsons.com>; Sat, 27 Oct 2018 11:15:17 -0500
>Received: from [172.18.96.2] (port=33431 helo=esrlnxsemxgwn01.esrin.esa.int)
>         by esrutmmgwext.esa.int with esmtps 
> (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256)
>         (Exim 4.82_1-5b7a7c0-XX)
>         (envelope-from <Mario.Merri at esa.int>)
>         id 1gGRF1-0005at-26; Sat, 27 Oct 2018 18:15:11 +0200
>Received: from esrlnxsemxgwn01.esrin.esa.int (localhost [127.0.0.1])
>         by localhost (Postfix) with SMTP id 79E7280125;
>         Sat, 27 Oct 2018 18:15:11 +0200 (CEST)
>Received: from esrlnxsimxgwn02.esrin.esa.int 
>(esrlnxmtaelb01-dmz.esrin.esa.int [172.18.96.5])
>         (using TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
>         (Client did not present a certificate)
>         by esrlnxsemxgwn01.esrin.esa.int (Postfix) with ESMTPS id 2A66780120;
>         Sat, 27 Oct 2018 18:15:11 +0200 (CEST)
>Received: from esrlnxsimxgwn02.esrin.esa.int (localhost [127.0.0.1])
>         by localhost (Postfix) with SMTP id 167BE100128;
>         Sat, 27 Oct 2018 18:15:11 +0200 (CEST)
>Received: from PMSGIMTA1A.esa-ad.esa.int (unknown [10.17.12.150])
>         (using TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
>         (No client certificate requested)
>         by esrlnxsimxgwn02.esrin.esa.int 
> (Postfix) with ESMTPS id ACB4310013C;
>         Sat, 27 Oct 2018 18:15:10 +0200 (CEST)
>X-CTCH-RefID: 
>str=0001.0A0C0201.5BD48F0F.0053,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
>In-Reply-To: <1c38de215c5c47b1a35a554be6c789df at ALHUN12EXCH02.Parsons.com>
>References: <1c38de215c5c47b1a35a554be6c789df at ALHUN12EXCH02.Parsons.com>
>To: "Weiss, Howard" <Howard.Weiss at parsons.com>
>CC: "brigitte.behal at cnes.fr" <brigitte.behal at cnes.fr>, 'Daniel.Fischer'
>         <Daniel.Fischer at esa.int>, "Shames, Peter M (313B)"
>         <peter.m.shames at jpl.nasa.gov>, CCSDS Secretariat
>         <secretariat at mailman.ccsds.org>
>Subject: Re: Application of CCSDS Protocols to Secure Systems Poll Condition
>X-KeepSent: 647E2CE0:01510806-C1258333:00591212;
>  type=4; name=$KeepSent
>X-Mailer: IBM Notes Release 9.0.1FP9 SHF55 October 04, 2017
>From: <Mario.Merri at esa.int>
>Message-ID: 
><11502_1540656911_5BD48F0E_11502_951_1_OF647E2CE0.01510806-ONC1258333.00591212-C1258333.005946F7 at esa.int>
>Date: Sat, 27 Oct 2018 18:15:08 +0200
>X-MIMETrack: Serialize by Router on 
>smtpmta1a/esrin/ESA at 10/27/2018 06:15:10 PM,
>         Serialize complete at 10/27/2018 06:15:10 PM
>Content-Type: multipart/alternative;
>         boundary="=_alternative 005946ADC1258333_="
>X-PMX-ESA-Disclaimer: yes
>X-Proofpoint-SPF-Result: pass
>X-Proofpoint-SPF-Record: v=spf1 mx 
>a:escutmmgwext.esa.int a:esrutmmgwext.esa.int ip4:131.176.79.225
>  ip4:131.176.154.65 ~all
>X-Proofpoint-Virus-Version: vendor=fsecure 
>engine=2.50.10434:,, definitions=2018-10-27_06:,,
>  signatures=0
>X-Proofpoint-Spam-Details: rule=notspam 
>policy=default score=0 suspectscore=0 malwarescore=0
>  phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999
>  adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
>  engine=8.0.1-1807170000 definitions=main-1810270150
>Return-Path: mario.merri at esa.int
>X-MS-Exchange-Organization-Network-Message-Id: 
>818162a7-e249-4543-5ba3-08d63c27617a
>X-MS-Exchange-Organization-AuthSource: TXDAL11EXCH01.Parsons.com
>X-MS-Exchange-Organization-AuthAs: Anonymous
>MIME-Version: 1.0
>
>Hi Howie,
>
>I still do not think that SLE is a protocol, but 
>my was just a suggestion not a condition.
>
>Thanks,
>
>__Mario
>
>
>
>From:        "Weiss, Howard" <Howard.Weiss at parsons.com>
>To:        "Mario.Merri at esa.int" <Mario.Merri at esa.int>
>Cc:        CCSDS Secretariat 
><secretariat at mailman.ccsds.org>, 
>"brigitte.behal at cnes.fr" 
><brigitte.behal at cnes.fr>, "'Daniel.Fischer'" 
><Daniel.Fischer at esa.int>, "Weiss, Howard" 
><Howard.Weiss at parsons.com>, "Shames, Peter M 
>(313B)" <peter.m.shames at jpl.nasa.gov>
>Date:        26/10/2018 16:37
>Subject:        Application of CCSDS Protocols 
>to Secure Systems Poll Condition
>
>
>
>Mario,
>
>
>
>In your review of the Application of CCSDS 
>Protocols to Secure Systems you made a “suggestion:”
>
>
>
> From the title the book should cover security 
> in CCSDS "protocols", however it also touches 
> on SLE which is more a service than a protocol. 
> In this context, the future version of the 
> green book should have provision to include 
> security aspects also of other CCSDS 
> application services, namely the MO Services.
>
>
>
>At the Berlin meetings, the Security Working Group discussed your suggestion.
>
>
>
>We consider SLE to be a protocol that provides a 
>set of capabilities (per the CCSDS glossary). In 
>the section with SLE, we have tried to 
>illustrate the implications of security on 
>various CCSDS protocols including SLE. SLE was 
>not transparent to security which made it a good 
>example. In the future, if other protocols are 
>impacted by security, they too will be included in revisions of the document.
>
>
>
>Does this satisfy your condition/suggestion?
>
>
>
>Regards
>
>howie
>
>
>
>----------
>
>Howard Weiss, CISSP
>
>PARSONS, Inc.
>
>7110 Samuel Morse Dr
>
>Suite 200
>
>Columbia, MD 21046
>
>443-430-8089 (office)
>
>443-494-9087 (cell)
>
>443-430-8238 (fax)
>
>
>
>
>NOTICE: This email message and all attachments 
>transmitted with it may contain privileged and 
>confidential information, and information that 
>is protected by, and proprietary to, Parsons 
>Corporation, and is intended solely for the use 
>of the addressee for the specific purpose set 
>forth in this communication. If the reader of 
>this message is not the intended recipient, you 
>are hereby notified that any reading, 
>dissemination, distribution, copying, or other 
>use of this message or its attachments is 
>strictly prohibited, and you should delete this 
>message and all copies and backups thereof. The 
>recipient may not further distribute or use any 
>of the information contained herein without the 
>express written authorization of the sender. If 
>you have received this message in error, or if 
>you have any questions regarding the use of the 
>proprietary information contained therein, 
>please contact the sender of this message 
>immediately, and the sender will provide you with further instructions.
>
>
>
>
>This message is intended only for the 
>recipient(s) named above. It may contain proprietary information and/or
>protected content. Any unauthorised disclosure, 
>use, retention or dissemination is prohibited. If you have received
>this e-mail in error, please notify the sender 
>immediately. ESA applies appropriate organisational measures to protect
>personal data, in case of data privacy queries, 
>please contact the ESA Data Protection Officer (dpo at esa.int).
>
>
>Received: from VACEN01EXCH02.Parsons.com (10.62.108.72) by
>  ALHUN12EXCH02.Parsons.com (10.62.8.72) with Microsoft SMTP Server (TLS) id
>  15.0.1367.3 via Mailbox Transport; Fri, 26 Oct 2018 10:59:15 -0500
>Received: from TXDAL11EXCH01.Parsons.com (172.21.212.127) by
>  VACEN01EXCH02.Parsons.com (10.62.108.72) with Microsoft SMTP Server (TLS) id
>  15.0.1367.3; Fri, 26 Oct 2018 11:59:09 -0400
>Received: from txdal11mx03.parsons.com (206.219.199.111) by
>  TXDAL11EXCH01.Parsons.com (172.21.212.127) with Microsoft SMTP Server (TLS)
>  id 15.0.1367.3 via Frontend Transport; Fri, 26 Oct 2018 10:59:09 -0500
>Received: from pps.filterd (txdal11mx03.parsons.com [127.0.0.1])
>         by txdal11mx03.parsons.com 
> (8.16.0.21/8.16.0.21) with SMTP id w9QFuTah028675
>         for <howard.weiss at parsons.com>; Fri, 26 Oct 2018 10:59:08 -0500
>Authentication-Results: parsons.com;
>         spf=pass smtp.mailfrom=jonathan.j.wilmot at nasa.gov;
>         dkim=pass header.d=nasa.gov header.s=letsgomars;
>         dmarc=pass header.from=nasa.gov
>Received: from ndjsvnpf104.ndc.nasa.gov 
>(ndjsvnpf104.ndc.nasa.gov [198.117.1.154])
>         by txdal11mx03.parsons.com with ESMTP id 2nc20p969v-1
>         (version=TLSv1.2 
> cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
>         for <Howard.Weiss at parsons.com>; Fri, 26 Oct 2018 10:59:08 -0500
>X-Comment: SPF check N/A for local connections - 
>client-ip=198.117.1.144; 
>helo=ndjsppt202.ndc.nasa.gov; 
>envelope-from=jonathan.j.wilmot at nasa.gov; receiver=daniel.fischer at esa.int
>DKIM-Filter: OpenDKIM Filter v2.11.0 ndjsvnpf104.ndc.nasa.gov 31410400812B
>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov;
>         s=letsgomars; t=1540569545;
>         bh=NPyFcP6nDBlWRnObp5xdiwrBdWAxJY2vae+u9a42aqA=;
>         h=Subject:To:CC:References:From:Date:In-Reply-To:From;
>         b=BVRLAw/0GxjJrMH4LH4S4fXOyTd1vIog6wAD0qfbvhSc2yMzfH19DMLd3aj5FGLSJ
>         13Nj76rFx3txaEsvI0BWZr7AnVDJEY4vCOilZnPM1w0LfPnEP0yRAVuVylDJPKJM16
>         jGm3P6lcvIJaj8u0WMTKrQxxMPrJDPgtms9Xs6irbFbJBRQzW2NVnL7pMVPjjPRjep
>         Gac+gwM2R1y/ikogKu31ssnvzlkODJMBe59UUSzNOWwSoeFaBfQiZ/POkP1rVQKuBC
>         6jKhlUkUDQGjLbTnrt7P4kfXRI1/7PEF6e556ApdUgBAPVbrifeA/8usDLe7IkGa/0
>         63fgsSYQ99pTg==
>Received: from ndjsppt202.ndc.nasa.gov 
>(NDJSPPT202.ndc.nasa.gov [198.117.1.144])
>         by ndjsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 31410400812B;
>         Fri, 26 Oct 2018 10:59:05 -0500 (CDT)
>Received: from pps.filterd (ndjsppt202.ndc.nasa.gov [127.0.0.1])
>         by ndjsppt202.ndc.nasa.gov 
> (8.16.0.22/8.16.0.22) with SMTP id w9QFn1kZ003460;
>         Fri, 26 Oct 2018 10:59:05 -0500
>Received: from ndjscht113.ndc.nasa.gov 
>(ndjscht113-sc.ndc.nasa.gov [198.117.1.183])
>         by ndjsppt202.ndc.nasa.gov with ESMTP id 2nc5h4g7hv-1;
>         Fri, 26 Oct 2018 10:59:05 -0500
>Received: from [198.120.194.166] (198.120.194.166) by smtp01.ndc.nasa.gov
>  (198.117.1.213) with Microsoft SMTP Server 
> (TLS) id 14.3.382.0; Fri, 26 Oct 2018 10:59:04 
> -0500Subject: Re: Application of CCSDS 
> Protocols to Secure Systems Poll Condition
>To: "Weiss, Howard" <Howard.Weiss at parsons.com>
>CC: CCSDS Secretariat <secretariat at mailman.ccsds.org>, 'Daniel.Fischer'
>         <Daniel.Fischer at esa.int>
>References: <c5f1ecf99c184e119347bfe93ede5528 at ALHUN12EXCH02.Parsons.com>
>From: Jonathan Wilmot <Jonathan.J.Wilmot at NASA.gov>
>Message-ID: <02787229-f619-932b-ba20-67b3e01652e9 at NASA.gov>
>Date: Fri, 26 Oct 2018 11:59:03 -0400
>User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
>  Thunderbird/52.5.2
>In-Reply-To: <c5f1ecf99c184e119347bfe93ede5528 at ALHUN12EXCH02.Parsons.com>
>Content-Type: text/html; charset="windows-1252"
>Content-Language: en-US
>Content-Transfer-Encoding: 8bit
>X-Originating-IP: [198.120.194.166]
>X-Proofpoint-Virus-Version: vendor=fsecure 
>engine=2.50.10434:,, definitions=2018-10-26_08:,,
>  signatures=0
>X-Proofpoint-SPF-Result: pass
>X-Proofpoint-SPF-Record: v=spf1 mx 
>include:_spf-ip4a.nasa.gov include:_spf-ip4b.nasa.gov
>  include:_spf-ip4c.nasa.gov include:_spf-ip4g.nasa.gov
>  include:_spf-ip4m.nasa.gov include:_spf-ip4x.nasa.gov
>  include:spf.protection.outlook.com -all
>X-Proofpoint-Virus-Version: vendor=fsecure 
>engine=2.50.10434:,, definitions=2018-10-26_08:,,
>  signatures=0
>X-Proofpoint-Spam-Details: rule=notspam 
>policy=default score=0 suspectscore=1 malwarescore=0
>  phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999
>  adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
>  engine=8.0.1-1807170000 definitions=main-1810260134
>Return-Path: jonathan.j.wilmot at nasa.gov
>X-MS-Exchange-Organization-Network-Message-Id: 
>b4958bd2-efd8-427a-12d4-08d63b5bf752
>X-MS-Exchange-Organization-AuthSource: TXDAL11EXCH01.Parsons.com
>X-MS-Exchange-Organization-AuthAs: Anonymous
>MIME-Version: 1.0
>
>
>Received: from VACEN01EXCH01.Parsons.com (10.62.108.71) by
>  ALHUN12EXCH02.Parsons.com (10.62.8.72) with Microsoft SMTP Server (TLS) id
>  15.0.1367.3 via Mailbox Transport; Fri, 26 Oct 2018 10:43:06 -0500
>Received: from TXDAL11EXCH01.Parsons.com (172.21.212.127) by
>  VACEN01EXCH01.Parsons.com (10.62.108.71) with Microsoft SMTP Server (TLS) id
>  15.0.1367.3; Fri, 26 Oct 2018 11:43:01 -0400
>Received: from txdal11mx02.parsons.com (206.219.199.110) by
>  TXDAL11EXCH01.Parsons.com (172.21.212.127) with Microsoft SMTP Server (TLS)
>  id 15.0.1367.3 via Frontend Transport; Fri, 26 Oct 2018 10:43:01 -0500
>Received: from pps.filterd (txdal11mx02.parsons.com [127.0.0.1])
>         by txdal11mx02.parsons.com 
> (8.16.0.21/8.16.0.21) with SMTP id w9QFfM9j030227
>         for <howard.weiss at parsons.com>; Fri, 26 Oct 2018 10:43:01 -0500
>Authentication-Results: parsons.com;
>         spf=pass smtp.mailfrom=David.S.Berry at jpl.nasa.gov;
>         dkim=pass header.d=jpl.nasa.gov header.s=JPL1810;
>         dmarc=pass header.from=jpl.nasa.gov
>Received: from ppa02.jpl.nasa.gov (ppa02.jpl.nasa.gov [128.149.137.113])
>         by txdal11mx02.parsons.com with ESMTP id 2nc5qa81am-1
>         (version=TLSv1.2 
> cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
>         for <Howard.Weiss at parsons.com>; Fri, 26 Oct 2018 10:43:00 -0500
>Received: from pps.filterd (ppa02.jpl.nasa.gov [127.0.0.1])
>         by ppa02.jpl.nasa.gov 
> (8.16.0.21/8.16.0.21) with SMTP id w9QFe1uV167414;
>         Fri, 26 Oct 2018 08:42:58 -0700
>DKIM-Signature: v=1; a=rsa-sha256; 
>c=relaxed/simple; d=jpl.nasa.gov; h=from : to : cc :
>  subject : date : message-id : references : in-reply-to : content-type :
>  mime-version; s=JPL1810; bh=8UDOFXzstttTmMxcBgZb1CU6vg61owbRffILkAkAYk8=;
>  b=mKusyK/PFgmcyWxUsPxu/vZrGACOSlzJfDk1xTxhxiL6uJ8LRC02l/XJueKNCaJQdkIj
>  LOVXB+16qDwjNb+KLN7EkbjQQO0nz3PWBgw1gORbGcuz4Op2Fn9Jkt7GHnZBGhOFRmp1
>  6G8+gOwhzLRwphueM6zFrGM9B06lFMMUAmfssB4RgTNKDDjiRks8WePohtCjrC+pyZ3l
>  XXU6jVDeXAZX8A6pA+8hXu4/TYevxYnbzMdUNgEbQdkiZULiWeTp4ZuCYUT/n+kpWdvQ
>  SRHN97Wd2BiROqhXVaEaa/+vWPBpRrNAKPZt/LmMKF5BSSNxI6qz7oOFNc8h5Zgx7c0d lA==
>Authentication-Results: jpl.nasa.gov;
>         spf=none smtp.mailfrom=David.S.Berry at jpl.nasa.gov
>Received: from mail.jpl.nasa.gov 
>(altphysenclup02.jpl.nasa.gov [128.149.137.53])
>         by ppa02.jpl.nasa.gov with ESMTP id 2nb0e4df2d-1
>         (version=TLSv1.2 
> cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
>         Fri, 26 Oct 2018 08:42:58 -0700
>Received: from mail.jpl.nasa.gov 
>(ap-embx16-sp20.jpl.nasa.gov [128.149.137.84])
>         by smtp.jpl.nasa.gov 
> (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id w9QFgvwJ004138
>         (using TLSv1.2 with cipher 
> ECDHE-RSA-AES128-SHA256 (128 bits) verified OK);
>         Fri, 26 Oct 2018 08:42:58 -0700
>Received: from ap-embx16-sp40.RES.AD.JPL (2002:8095:8956::8095:8956) by
>  ap-embx16-sp20.RES.AD.JPL (2002:8095:8954::8095:8954) with Microsoft SMTP
>  Server (version=TLS1_2, 
> cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
>  15.1.1531.3; Fri, 26 Oct 2018 08:42:56 -0700
>Received: from ap-embx16-sp40.RES.AD.JPL ([fe80::2160:fabd:7816:8857]) by
>  ap-embx16-sp40.RES.AD.JPL ([fe80::2160:fabd:7816:8857%17]) with mapi id
>  15.01.1531.003; Fri, 26 Oct 2018 08:42:57 -0700
>From: "Berry, David S (3920)" <David.S.Berry at jpl.nasa.gov>
>To: "Weiss, Howard" <Howard.Weiss at parsons.com>
>CC: CCSDS Secretariat <secretariat at mailman.ccsds.org>
>Subject: Re: RID Disposition - information security glossary
>Thread-Topic: RID Disposition - information security glossary
>Thread-Index: AdRtLRqanyFqFidqRXmJNr/sTqzMiQAFXXgA
>Date: Fri, 26 Oct 2018 15:42:57 +0000
>Message-ID: <826B72A8-5250-4CE2-9FFA-D62EC09B008F at jpl.nasa.gov>
>References: <f7700c969a334ce89934b0b1d6fed607 at ALHUN12EXCH02.Parsons.com>
>In-Reply-To: <f7700c969a334ce89934b0b1d6fed607 at ALHUN12EXCH02.Parsons.com>
>Accept-Language: en-US
>Content-Language: en-US
>X-MS-Has-Attach:
>X-MS-TNEF-Correlator:
>user-agent: Microsoft-MacOutlook/10.10.3.181015
>x-originating-ip: [207.151.104.72]
>Content-Type: multipart/alternative;
>         boundary="_000_826B72A852504CE29FFAD62EC09B008Fjplnasagov_"
>X-Source-IP: ap-embx16-sp20.jpl.nasa.gov [128.149.137.84]
>X-Source-Sender: David.S.Berry at jpl.nasa.gov
>X-AUTH: Authorized
>X-Proofpoint-Virus-Version: vendor=fsecure 
>engine=2.50.10434:,, definitions=2018-10-26_08:,,
>  signatures=0
>X-Proofpoint-Spam-Details: rule=outbound_notspam 
>policy=outbound score=0 priorityscore=1501
>  malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0
>  clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0
>  mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx
>  scancount=1 engine=8.0.1-1807170000 definitions=main-1810260132
>X-Proofpoint-SPF-Result: pass
>X-Proofpoint-SPF-Record: v=spf1 
>ip4:128.102.200.15/32 ip4:128.149.0.0/16 ip4:128.149.139.0/24
>  ip4:128.183.0.0/16 ip4:128.156.250.70/32 ip4:129.164.30.24/32
>  ip4:128.183.0.0/16 ip4:137.78.0.0/16 ip4:137.79.160.134/32
>  ip4:198.116.65.188/32 ip4:198.117.0.0/24 ip4:198.117.1.0/24
>  ip4:198.122.193.66/32 ip4:207.151.216.0/22 ip4:199.255.192.0/22
>  ip4:199.127.232.0/22 ip4:54.240.0.0/18 ip4:69.169.224.0/20
>  include:icpbounce.com include:amazonses.com -all
>X-Proofpoint-Virus-Version: vendor=fsecure 
>engine=2.50.10434:,, definitions=2018-10-26_08:,,
>  signatures=0
>X-Proofpoint-Spam-Details: rule=notspam 
>policy=default score=0 suspectscore=0 malwarescore=0
>  phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999
>  adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
>  engine=8.0.1-1807170000 definitions=main-1810260131
>Return-Path: David.S.Berry at jpl.nasa.gov
>X-MS-Exchange-Organization-Network-Message-Id: 
>ff4290dd-edf5-4fdc-b6b2-08d63b59b644
>X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
>X-MS-Exchange-Organization-AuthSource: TXDAL11EXCH01.Parsons.com
>X-MS-Exchange-Organization-AuthAs: Anonymous
>MIME-Version: 1.0
>
>Confirmed.
>
>Thanks Howie!
>
>DSB
>
>
>
>From: "Weiss, Howard" <Howard.Weiss at parsons.com>
>Date: Friday, October 26, 2018 at 6:11 AM
>To: "Berry, David S (3920)" <David.S.Berry at jpl.nasa.gov>
>Cc: CCSDS Secretariat 
><secretariat at mailman.ccsds.org>, "Weiss, Howard" <Howard.Weiss at parsons.com>
>Subject: RID Disposition - information security glossary
>
>David,
>
>You submitted the following RID against the Information Security Glossary:
>
>This is a good document, however, it's not clear 
>how this book can be listed as a normative 
>reference in any CCSDS document. It would seem 
>that it would have to be reclassified as a Blue 
>Book, Magenta Book, or "Yellow Book that is 
>normative upon CCSDS itself" in order to be so 
>listed. Most Green Books  end up in an "Informative References" annex.
>
>In response, the glossary has been changed from 
>a Green Book to a Magenta Book for exactly the 
>reason you state – so thatt it can be a normative reference.
>
>I hope this answers your RID satisfactorily.
>
>Regards
>
>howie
>
>----------
>Howard Weiss, CISSP
>PARSONS, Inc.
>7110 Samuel Morse Dr
>Suite 200
>Columbia, MD 21046
>443-430-8089 (office)
>443-494-9087 (cell)
>443-430-8238 (fax)
>
>
>NOTICE: This email message and all attachments 
>transmitted with it may contain privileged and 
>confidential information, and information that 
>is protected by, and proprietary to, Parsons 
>Corporation, and is intended solely for the use 
>of the addressee for the specific purpose set 
>forth in this communication. If the reader of 
>this message is not the intended recipient, you 
>are hereby notified that any reading, 
>dissemination, distribution, copying, or other 
>use of this message or its attachments is 
>strictly prohibited, and you should delete this 
>message and all copies and backups thereof. The 
>recipient may not further distribute or use any 
>of the information contained herein without the 
>express written authorization of the sender. If 
>you have received this message in error, or if 
>you have any questions regarding the use of the 
>proprietary information contained therein, 
>please contact the sender of this message 
>immediately, and the sender will provide you with further instructions.
>Received: from ALHUN12EXCH02.Parsons.com (10.62.8.72) by
>  ALHUN12EXCH02.Parsons.com (10.62.8.72) with Microsoft SMTP Server (TLS) id
>  15.0.1367.3 via Mailbox Transport; Fri, 4 Jan 2019 16:48:58 -0600
>Received: from TXDAL11EXCH01.Parsons.com (172.21.212.127) by
>  ALHUN12EXCH02.Parsons.com (10.62.8.72) with Microsoft SMTP Server (TLS) id
>  15.0.1367.3; Fri, 4 Jan 2019 16:48:54 -0600
>Received: from txdal11mx05.parsons.com (206.219.199.115) by
>  TXDAL11EXCH01.Parsons.com (172.21.212.127) with Microsoft SMTP Server (TLS)
>  id 15.0.1367.3 via Frontend Transport; Fri, 4 Jan 2019 16:48:54 -0600
>Received: from pps.filterd (txdal11mx05.parsons.com [127.0.0.1])
>         by txdal11mx05.parsons.com 
> (8.16.0.21/8.16.0.21) with SMTP id x04MikbB019555
>         for <howard.weiss at parsons.com>; Fri, 4 Jan 2019 16:48:54 -0600
>Authentication-Results: parsons.com;
>         spf=pass smtp.mailfrom=Scott.C.Burleigh at jpl.nasa.gov;
>         dkim=pass header.d=jpl.nasa.gov header.s=JPL1810;
>         dmarc=pass header.from=jpl.nasa.gov
>Received: from ppa02.jpl.nasa.gov (ppa02.jpl.nasa.gov [128.149.137.113])
>         by txdal11mx05.parsons.com with ESMTP id 2psufjv8nn-1
>         (version=TLSv1.2 
> cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
>         for <Howard.Weiss at parsons.com>; Fri, 04 Jan 2019 16:48:52 -0600
>Received: from pps.filterd (ppa02.jpl.nasa.gov [127.0.0.1])
>         by ppa02.jpl.nasa.gov 
> (8.16.0.21/8.16.0.21) with SMTP id x04MjnXT088405;
>         Fri, 4 Jan 2019 14:48:42 -0800
>DKIM-Signature: v=1; a=rsa-sha256; 
>c=relaxed/simple; d=jpl.nasa.gov; h=from : to : cc :
>  subject : date : message-id : references : in-reply-to : content-type :
>  mime-version; s=JPL1810; bh=RWwC/h9Q/UoLM8ghbB2ufKXxLjJ+pjlXB1eL6vV5dBI=;
>  b=B7KMa/y4vzJKhzY3OFbKWGOsoZb9pmnmtwkimJaWRR6KlQL/vsOPh9w5J42IRt54l8Qu
>  Dr5orUMc/RMdh01GBoU0ZzE9MZG3DeZuvcpowBO3cl5VqCD5X4i7fZ5+uq1uazKscYry
>  kInwiRUeRfCO427pPRPrdD4deuW7XHRUUVgArfGXYBiD2SG42vDJAYPdlGBgRJZisuNy
>  wKcNQ9MccIklVlyA2qpBl6NATUR/igfx2z7NjvVXSNuok2/GWPeryHM1uOgZArrUd1cH
>  mqw8qc42/NQM/n9aWjQD6+3gWjOM/Nu4fjkVmbYCVDVID6lqBEDLHHZYtM5foe8K/S7K rQ==
>Authentication-Results: jpl.nasa.gov;
>         spf=none smtp.mailfrom=Scott.C.Burleigh at jpl.nasa.gov
>Received: from mail.jpl.nasa.gov 
>(altphysenclup03.jpl.nasa.gov [128.149.137.120])
>         by ppa02.jpl.nasa.gov with ESMTP id 2pss1q35c7-1
>         (version=TLSv1.2 
> cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
>         Fri, 04 Jan 2019 14:48:41 -0800
>Received: from mail.jpl.nasa.gov 
>(ap-embx16-sp40.jpl.nasa.gov [128.149.137.86])
>         by smtp.jpl.nasa.gov 
> (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id x04MmeIT001341
>         (using TLSv1.2 with cipher 
> ECDHE-RSA-AES128-SHA256 (128 bits) verified OK);
>         Fri, 4 Jan 2019 14:48:41 -0800
>Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by
>  ap-embx16-sp40.RES.AD.JPL (2002:8095:8956::8095:8956) with Microsoft SMTP
>  Server (version=TLS1_2, 
> cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
>  15.1.1531.3; Fri, 4 Jan 2019 14:48:40 -0800
>Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by
>  ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id
>  15.01.1531.008; Fri, 4 Jan 2019 14:48:40 -0800
>From: "Burleigh, Scott C (312B)" <Scott.C.Burleigh at jpl.nasa.gov>
>To: "Weiss, Howard" <Howard.Weiss at parsons.com>
>CC: 'Daniel.Fischer' <Daniel.Fischer at esa.int>, "'Biggerstaff, Craig
>  (JSC-CD221)[LOCKHEED MARTIN CORP]'" <craig.biggerstaff at nasa.gov>
>Subject: RE: Application of CCSDS Protocols to Secure Systems Poll Condition
>Thread-Topic: Application of CCSDS Protocols to Secure Systems Poll Condition
>Thread-Index: 
>AdRtOXCRnplDtyasQiaGLE4/9P7PIgAD117wAAFuPmAAAHFlwA2/UdfAAAGDCqAABa2t8AAEpFtw
>Date: Fri, 4 Jan 2019 22:48:40 +0000
>Message-ID: <7bf194d3648d4cbc92de1c82012a4334 at jpl.nasa.gov>
>References: <819d9b5054a4433696aa26fc161362c2 at ALHUN12EXCH02.Parsons.com>
>  <82604182e3584313a991bb1630d1d07c at jpl.nasa.gov>
>  <4be86a283dc64ee88a8f0ab09ec13923 at ALHUN12EXCH02.Parsons.com>
>  <9796d8cd18a941b4827760b1fcec6902 at jpl.nasa.gov>
>  <ad59d3f809794b9bab4c9c3f8f4e354e at ALHUN12EXCH02.Parsons.com>
>  <69561e1cbc7545c8b6478c719aec59a9 at jpl.nasa.gov>
>  <02830718965841eba73baf2509f24e7b at ALHUN12EXCH02.Parsons.com>
>In-Reply-To: <02830718965841eba73baf2509f24e7b at ALHUN12EXCH02.Parsons.com>
>Accept-Language: en-US
>Content-Language: en-US
>X-MS-Has-Attach: yes
>X-MS-TNEF-Correlator:
>x-originating-ip: [207.151.104.72]
>Content-Type: multipart/mixed;
>         boundary="_79d18cc6-e2c4-4c72-9216-1f0ab73ea7b9_"
>X-Source-IP: ap-embx16-sp40.jpl.nasa.gov [128.149.137.86]
>X-Source-Sender: Scott.C.Burleigh at jpl.nasa.gov
>X-AUTH: Authorized
>X-Proofpoint-Virus-Version: vendor=fsecure 
>engine=2.50.10434:,, definitions=2019-01-04_11:,,
>  signatures=0
>X-Proofpoint-Spam-Details: rule=outbound_notspam 
>policy=outbound score=0 priorityscore=1501
>  malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0
>  clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0
>  mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx
>  scancount=1 engine=8.0.1-1810050000 definitions=main-1901040190
>X-CLX-Shades: MLX
>X-CLX-Response: 
>1TFkXGx4aEQpMehcaEQpZTRdnZnIRCllJFxpxGhAadwYbGBpxGx8QGncGGBo 
>GGhEKWV4XbGx5EQpJRhdaS1hZRURZdVpYRU5fSV5DRUQHXEceEQpDThcYbENsTHhdRXVGH1tke2 
>luHm1AeUl9G21dSH1LcGZocBEKWFwXHwQaBBsfHQceHEtJG0xIHAUbGgQbGhoEHhIEHxAbHhofG
> 
>hEKXlkXfnBzTl0RCk1cFxkcGxEKTFoXaGtrEQpNThdoEQpMRhdnb2trYmtrEQpDWhcbGBIEGx4T 
>BBsZHQQbGxkRCkJeFxsRCkRJFxgRCkJcFxsRCkJLF3p/SFNLGB9JH1gbEQpCSRdnRFx7WmdnXXx 
>TSBEKQkUXYFBJb2V9aX5yQk8RCkJOF2dEXHtaZ2ddfFNIEQpCTBd6QkVda0VmRHlacBEKQmwXaH
> 
>lmRU5DHllYAVoRCkJAF2B/WklrXkwfbxtGEQpCWBdtYUZFExl5ckZaQxEKWlgXGxEKcGcXbWwcA 
>UJMRnBdRGwQHRoRCnBoF2JMfBxYGmZFBU0SEBoRCnBoF2ZaHVpsQ3IdH2VoEBoRCnBoF3piTXJh 
>fFIfWxNdEBoRCnBoF2ddT3ljWk1jYX5hEBkaEQpwaBdjAV0YTAVHTWBIQhAaEQpwZxdiaGxcZUY
> 
>Bfh8eQBAeEhEKcGcXemsSXFlHW09re3gQGx4bEQpwbBdiekwSAWYaW3lGUhAZGhEKcEwXZmUeXF 
>JZfUIYHF0QHhIRCm1+FxoRClhNF0sRIA==
>X-Proofpoint-SPF-Result: pass
>X-Proofpoint-SPF-Record: v=spf1 
>ip4:128.102.200.15/32 ip4:128.149.0.0/16 ip4:128.149.139.0/24
>  ip4:128.183.0.0/16 ip4:128.156.250.70/32 ip4:129.164.30.24/32
>  ip4:128.183.0.0/16 ip4:137.78.0.0/16 ip4:137.79.160.134/32
>  ip4:198.116.65.188/32 ip4:198.117.0.0/24 ip4:198.117.1.0/24
>  ip4:198.122.193.66/32 ip4:207.151.216.0/22 ip4:199.255.192.0/22
>  ip4:199.127.232.0/22 ip4:54.240.0.0/18 ip4:69.169.224.0/20
>  include:icpbounce.com -all
>X-Proofpoint-Virus-Version: vendor=fsecure 
>engine=2.50.10434:,, definitions=2019-01-04_11:,,
>  signatures=0
>X-Proofpoint-Spam-Details: rule=notspam 
>policy=default score=0 priorityscore=0 malwarescore=0
>  suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=140
>  lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0
>  classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000
>  definitions=main-1901040190
>Return-Path: Scott.C.Burleigh at jpl.nasa.gov
>X-MS-Exchange-Organization-Network-Message-Id: 
>27c9a388-e3c7-4e80-8fa3-08d67296ce1d
>X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
>X-MS-Exchange-Organization-AuthSource: TXDAL11EXCH01.Parsons.com
>X-MS-Exchange-Organization-AuthAs: Anonymous
>MIME-Version: 1.0
>
>Howie, some further responses in-line 
>below.  This would be fun to discuss further 
>sometime, but meanwhile Happy New Year!
>
>Scott
>
>From: Weiss, Howard <Howard.Weiss at parsons.com>
>Sent: Friday, January 4, 2019 12:53 PM
>To: Burleigh, Scott C (312B) <Scott.C.Burleigh at jpl.nasa.gov>
>Cc: 'Daniel.Fischer' <Daniel.Fischer at esa.int>; 
>'Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN 
>CORP]' <craig.biggerstaff at nasa.gov>
>Subject: RE: Application of CCSDS Protocols to Secure Systems Poll Condition
>
>Scott
>
>See inline responses.
>
>howie
>
>From: Burleigh, Scott C (312B) 
><<mailto:Scott.C.Burleigh at jpl.nasa.gov>Scott.C.Burleigh at jpl.nasa.gov>
>Sent: Friday, January 04, 2019 1:44 PM
>To: Weiss, Howard <<mailto:Howard.Weiss at parsons.com>Howard.Weiss at parsons.com>
>Cc: 'Daniel.Fischer' 
><<mailto:Daniel.Fischer at esa.int>Daniel.Fischer at esa.int>; 
>'Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN 
>CORP]' <<mailto:craig.biggerstaff at nasa.gov>craig.biggerstaff at nasa.gov>
>Subject: RE: Application of CCSDS Protocols to Secure Systems Poll Condition
>
>Hi, Howie.  I didn’t realize that the purpose 
>of Figure 3.1 was to show where security comes 
>into play, and I agree that the ICSIS diagram isn’t helpful for that purpose.
>
>As stated in the paragraph prior to the figure: 
>“Security may be applied at other layers 
>(e.g., the Transport Layer) if dictated by the 
>mission requirements.  However, this report 
>considers only the four security implementation 
>points, shown in figure 3‑1, that are likely 
>to satisfy the requirements of most 
>missions.  Figure 3‑1 does not show all 
>possible CCSDS protocol combinations.”
>
>Actually, I’ve caught an error since we are 
>now illustrating more than 4 security 
>implementation points in this revision.  I will fix this.
>
>I’m not wild about your replacement diagram, 
>though, for a couple of reasons.
>
>First, I would say the original ISO layering 
>model isn’t really relevant here or, really, 
>much of anywhere any more.  When you do mobile 
>IP, you’ve got IP packets encapsulated in IP 
>packets, right?  Which IP header is at layer 3 
>(network), and which layer is the other one at?
>
>I disagree.  The ISO model is still *the* 
>network layering model understood by the masses 
>– at least the lower 4 laayers and layer 7.  Our 
>intent was to show the intersection between the 
>CCSDS protocols, the internet protocols, and the 
>OSI model.  Certainly, encapsulation perturbs 
>clean layering, but the model is still a valid 
>representation and provides the commonly 
>understand framework that we are illustrating. 
>Clean layering was broken may years ago, yet we 
>still talk about the network layer at layer 3 
>and the transport layer at layer 4.
>
>*** I could not disagree more.  “Clean 
>layering” means that the upper and lower 
>interfaces at each layer are “clean”, i.e., 
>two adjacent layers can invoke all necessary 
>functions of each other strictly by exercising 
>the interfaces rather than by invoking each 
>other’s internal functions.  Clean layering is 
>certainly not broken.  Encapsulation doesn’t 
>perturb clean layering; it is the essence of 
>layering.  Pretending that the networking world 
>still cares about session layers, or that the 
>protocol stack has exactly 7 layers, is not clean.
>
>The concept of protocol layering is more 
>important than ever, but trying to fit modern 
>network architectures into those 7 layers with 
>those 7 names is no longer helpful.  (As is 
>evident from your own diagram, where it has been 
>necessary to replace layer 2 – “Data Link” – 
>with two layers nameamed “Data Link” and 
>“Synchronization and Channel 
>Coding”.)  Layers 5 (Session) and 6 
>(Presentation) are no longer remotely applicable 
>– neither one accuratelyy characterizes Bundle 
>Protocol – but the Convergence layer between BP 
>and the stuff below it (which might be Transport 
>in nature, or might be Network, or might be Data 
>Link) is very real and must not be omitted from the picture.
>
>As you note, we added additional language to 
>layer 2 in order to illustrate that the CCSDS 
>protocols didn’t map cleanly onto the OSI 
>model.  Layers 5 and 6 were *never* applicable 
>because no one really understood their usage and 
>hence applications typically accessed the 
>transport layer directly. We continue to show 
>those layers because we are adhering to the OSI 
>layers for illustrative purposes.  There is no 
>“official” layer called the “bundle 
>layer” or the “convergence layer” and 
>I’m sure there would be push-back if we were 
>to do a wholesale model modification.  One could 
>argue that the bundle layer is a presentation 
>layer and the convergence layer is a session layer.
>
>*** No, one could not.  The OSI model includes 
>definitions of the functions of those layers, 
>and those definitions do not remotely apply to 
>the bundle layer and convergence layer.
>
>*** As an aside, I think the concept of a 
>“bundle layer” is itself highly 
>unfortunate.  BP is a network protocol.  You can 
>tunnel BP through IP, and you can tunnel IP 
>through BP.  Sadly we seem to be stuck with “bundle layer” as a thing.
>
>Hence our figure tries to represent the bundle 
>protocol across layers 5 and 6 without going 
>into detail.  Likewise we don’t go into detail 
>for any other protocol.  This is not meant to be 
>a detailed protocol breakout diagram.  Rather 
>its supposed to be a high level representation 
>of the protocols as mapped to OSI layers and where security can be applied.
>
>Moreover, the new diagram erases one notable 
>distinction between IPSec and BP security 
>protocol.  IPSec Authentication Headers actually 
>constitute a separate layer in the stack, 
>immediately above [that is, encapsulated within] 
>IPv4, that encapsulates either IP packets (when 
>the AH is in tunnel mode) or TCP/UDP/ICMP 
>protocol data units (when the AH is in transport 
>mode).  That is, when AH is used, the protocol 
>identifier in the IPv4 packet is AH rather than 
>TCP, UDP, ICMP, whatever.  In contrast, BP 
>security is implemented as extension blocks 
>within BP rather than as an overlying layer.  I 
>think the diagram would be improved by showing the IPSec AH layer explicitly.
>
>Both AH and ESP have their own next protocol 
>numbers which are used in order to flag the use 
>of the security mechanisms.  I don’t agree 
>that AH (or ESP) is a separate layer.  Even more 
>pertinent is the lack of AH use.  Its usage is 
>generally discouraged because, from a security 
>perspective, it is weak.  It is highly 
>recommended that ESP be used with a null 
>encryption algorithm if only authentication is 
>desired.  However, we (and the security 
>community) don’t encourage authentication-only 
>and encourage the use of Authenticated 
>Encryption because of the additional security 
>strength received at almost no extra cost. We 
>can discuss the differences between IPSec and 
>SBSP in the subsequent sections rather than 
>going into gory detail in a high level diagram.
>
>Again, we are not trying to illustrate protocol 
>details – only high level mappings along witth 
>the layers at which security may be 
>employed.  The document then describes the 
>strengths and weaknesses of security employed at the various layers.
>
>I think we are getting closer, but I think 
>it’s worthwhile to try to make this 
>illustration as accurate as we reasonably can.
>
>I agree with accuracy but it sounds like you are 
>asking for details in the figure that we are not 
>trying to illustrate. We are not breaking apart 
>and showing the details of any of the protocols.
>
>*** Okay.  I don’t agree, but I don’t feel 
>strongly enough about this to spend more time 
>tussling over it.  Please consider my conditions 
>fully satisfied by your spec revisions.
>
>Scott
>
>From: Weiss, Howard 
><<mailto:Howard.Weiss at parsons.com>Howard.Weiss at parsons.com>
>Sent: Friday, January 4, 2019 8:58 AM
>To: Burleigh, Scott C (312B) 
><<mailto:Scott.C.Burleigh at jpl.nasa.gov>Scott.C.Burleigh at jpl.nasa.gov>
>Cc: 'Daniel.Fischer' 
><<mailto:Daniel.Fischer at esa.int>Daniel.Fischer at esa.int>; 
>'Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN 
>CORP]' <<mailto:craig.biggerstaff at nasa.gov>craig.biggerstaff at nasa.gov>
>Subject: RE: Application of CCSDS Protocols to Secure Systems Poll Condition
>
>Scott,
>
>Happy New Year
.
> >
>Picking up on a seemingly dormant thread, I 
>wanted to run a new illustration by you.  You 
>provided a figure to replace our Figure 
>3-1.  However, it didn’t illustrate what we 
>were trying to show – namely wwhere security 
>comes into play.  Your figure also didn’t use 
>the ISO layering and renamed layers 5 & 6.
>
>We revised our diagram which we hope better 
>illustrates both of our desires (see attached).  What do you think?
>
>We are also working on the inclusion of a bundle 
>security discussion as you requested.
>
>Regards
>
>howie
>
>From: Burleigh, Scott C (312B) 
><<mailto:Scott.C.Burleigh at jpl.nasa.gov>Scott.C.Burleigh at jpl.nasa.gov>
>Sent: Friday, October 26, 2018 1:30 PM
>To: Weiss, Howard <<mailto:Howard.Weiss at parsons.com>Howard.Weiss at parsons.com>
>Cc: CCSDS Secretariat 
><<mailto:secretariat at mailman.ccsds.org>secretariat at mailman.ccsds.org>; 
>'Daniel.Fischer' <<mailto:Daniel.Fischer at esa.int>Daniel.Fischer at esa.int>
>Subject: RE: Application of CCSDS Protocols to Secure Systems Poll Condition
>
>Hi, Howie.  Pink Sheets would actually be fine 
>with me, but I thought they only applied to 
>updates to Blue Books, not Green Books.
>
>If you are okay with having this Green Book 
>reference work in progress, then I think the 
>right document would be the SBSP Red Book 
>734.5-R-1.  The original BSP spec is not a CCSDS 
>document and it’s not relevant to CCSDS 
>standardization of DTN, as it is actually 
>unimplementable in some configurations.
>
>Scott
>
>From: Weiss, Howard 
><<mailto:Howard.Weiss at parsons.com>Howard.Weiss at parsons.com>
>Sent: Friday, October 26, 2018 10:11 AM
>To: Burleigh, Scott C (312B) 
><<mailto:Scott.C.Burleigh at jpl.nasa.gov>Scott.C.Burleigh at jpl.nasa.gov>
>Cc: CCSDS Secretariat 
><<mailto:secretariat at mailman.ccsds.org>secretariat at mailman.ccsds.org>; 
>'Daniel.Fischer' <<mailto:Daniel.Fischer at esa.int>Daniel.Fischer at esa.int>
>Subject: RE: Application of CCSDS Protocols to Secure Systems Poll Condition
>
>Scott,
>
>I presume that you would like SBSP included even 
>though its still in flux?  Or would BSP be 
>preferable?  Another alternative is to issue 
>Pink Sheets to the book once SBSP is finalized and locked down.
>
>Regards
>
>howie
>
>From: Burleigh, Scott C (312B) 
><<mailto:Scott.C.Burleigh at jpl.nasa.gov>Scott.C.Burleigh at jpl.nasa.gov>
>Sent: Friday, October 26, 2018 12:44 PM
>To: Weiss, Howard <<mailto:Howard.Weiss at parsons.com>Howard.Weiss at parsons.com>
>Cc: CCSDS Secretariat 
><<mailto:secretariat at mailman.ccsds.org>secretariat at mailman.ccsds.org>; 
>'Daniel.Fischer' <<mailto:Daniel.Fischer at esa.int>Daniel.Fischer at esa.int>
>Subject: RE: Application of CCSDS Protocols to Secure Systems Poll Condition
>
>Hi, Howie.  I am expecting that the next 
>revision of this Green Book won’t be issued 
>until 2024, which is a long time to leave 
>prospective CCSDS security protocol users in the 
>dark about the security mechanisms available in 
>DTN.  It does the reader no favor to suggest 
>that the material in this Green Book is a 
>comprehensive survey of the application of CCSDS 
>protocols to secure systems when in fact it is 
>manifestly incomplete.  Since this is a Green 
>Book, I don’t think it would necessarily be 
>inappropriate to reference work in 
>progress.  But if you don’t want to do that, 
>then changing the title of the book as I 
>suggested would certainly address my condition.
>
>Here is a diagram from the Gateway standards 
>(ICSIS) that I think is pretty good:
>
>cid:image001.jpg at 01D4A410.FE2497B0
>
>
>I am fine with the other responses to my conditions.
>
>Thanks,
>Scott
>
>From: Weiss, Howard 
><<mailto:Howard.Weiss at parsons.com>Howard.Weiss at parsons.com>
>Sent: Friday, October 26, 2018 7:49 AM
>To: Burleigh, Scott C (312B) 
><<mailto:Scott.C.Burleigh at jpl.nasa.gov>Scott.C.Burleigh at jpl.nasa.gov>
>Cc: CCSDS Secretariat 
><<mailto:secretariat at mailman.ccsds.org>secretariat at mailman.ccsds.org>; 
>'Daniel.Fischer' 
><<mailto:Daniel.Fischer at esa.int>Daniel.Fischer at esa.int>; 
>Weiss, Howard <<mailto:Howard.Weiss at parsons.com>Howard.Weiss at parsons.com>
>Subject: Application of CCSDS Protocols to Secure Systems Poll Condition
>
>Scott,
>
>In your review of the Application of CCSDS 
>Protocols to Secure Systems, you approved it 
>with conditions.  The conditions were reviewed 
>by the Security Working Group last week in 
>Berlin and we would like to provide you with our response.
>
>You said:
>
>​I believe this Green Book is fine as far as 
>it goes.  But since its title is "The 
>Application of CCSDS Protocols to Secure 
>Systems" I think it is now required to include a 
>discussion of the Bundle Security Protocol, 
>which will be a CCSDS standard.  (Is there a 
>Blue Book for a CCSDS profile of ipsec?  If not, 
>then the discussion of ipsec should be omitted.) 
>Alternatively, the title could be changed to 
>something like "The Application of Space Data 
>Link Security Protocol and IPSEC to Secure Systems."
>
>    * Response: There is an IPSec profile BB 
> which was just published (356.0-B). However, 
> since this is a GB it affords us the ability to 
> expose it as a security option and therefore 
> would like to retain it.  As for bundle 
> security, it is not a published BB yet. We will 
> include it in the next revision of the document.
>On roughly the same topic, Figure 3.1 doesn't 
>get the layering of the DTN protocols right; I 
>think more accurate diagrams are available.
>
>    * Response: What changes would you like to 
> see (e.g., LTP)?  Can you point to an already 
> existing diagram that we can use?
>
>Page 2-2: I think insertion of new, counterfeit 
>information is an additional class of active threat.
>
>    * Response: We believe that this is already covered by case (b).
>
>Section 4.1.1: I think the distinction between 
>point-to-point and end-to-end security needs to be made clearer.
>
>    * Response: We will add the words “with no 
> intermediary systems in-between” to the 
> description of point-to-point in the figure.
>
>Do these responses allay your concerns/issues?
>
>Regards,
>
>howie
>----------
>
>Howard Weiss, CISSP
>PARSONS, Inc.
>7110 Samuel Morse Dr
>Suite 200
>Columbia, MD 21046
>443-430-8089 (office)
>443-494-9087 (cell)
>443-430-8238 (fax)
>
>
>NOTICE: This email message and all attachments 
>transmitted with it may contain privileged and 
>confidential information, and information that 
>is protected by, and proprietary to, Parsons 
>Corporation, and is intended solely for the use 
>of the addressee for the specific purpose set 
>forth in this communication. If the reader of 
>this message is not the intended recipient, you 
>are hereby notified that any reading, 
>dissemination, distribution, copying, or other 
>use of this message or its attachments is 
>strictly prohibited, and you should delete this 
>message and all copies and backups thereof. The 
>recipient may not further distribute or use any 
>of the information contained herein without the 
>express written authorization of the sender. If 
>you have received this message in error, or if 
>you have any questions regarding the use of the 
>proprietary information contained therein, 
>please contact the sender of this message 
>immediately, and the sender will provide you with further instructions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20190218/2256551e/attachment-0001.html>
-------------- next part --------------
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Howie,<br>
      <br>
        I agree with the responses. Consider the conditions closed.<br>
      <br>
         Kind regards,<br>
      <br>
              Jonathan<br>
      <br>
      On 10/26/2018 10:55 AM, Weiss, Howard wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:c5f1ecf99c184e119347bfe93ede5528 at ALHUN12EXCH02.Parsons.com">
      <meta http-equiv="Context-Type" content="text/html;
        charset=us-ascii">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <div class="WordSection1">
        <p class="MsoNormal">Jonathan,</p>
        <p class="MsoNormal"> </p>
        <p class="MsoNormal">In your review of the Application of CCSDS
          Protocols to Secure Systems, you approved it with conditions. 
          The conditions were reviewed by the Security Working Group
          last week in Berlin and we would like to provide you with our
          response.</p>
        <p class="MsoNormal"> </p>
        <p class="MsoNormal">You said:</p>
        <p class="MsoNormal"> </p>
        <p class="MsoNormal"><span>No mention of file level encryption. 
            Is this use case considered application layer security?</span></p>
        <p class="MsoNormal"> </p>
        <ul type="disc">
          <li class="MsoListParagraph"><b>Response</b>: yes.</li>
        </ul>
        <p class="MsoNormal"> </p>
        <p class="MsoNormal"><span class="fontstyle0"><span>Section 5.4.2
              SPACE PACKET PROTOCOL SECURITY</span></span><span> as
            recommended would not provide protection against replay
            attacks since the header is not authenticated. This could be
            made clear.</span></p>
        <p class="MsoNormal"> </p>
        <ul type="disc">
          <li class="MsoListParagraph"><b>Response</b>: You are correct,
            however this is only meant as a high-level example of how
            security
            <i>might</i> be applied to space packets and is not meant to
            be a specification for how it
            <i>should</i> be applied. An authenticated sequence number
            would have to be added to the primary header to counter
            replay and we did not attempt to specify changes to the
            space packet protocol in this document. We will add a note
            in the document to indicate that unless the protocol is
            modified (or the secondary header timecode seq counter is
            used), it is subject to replay attacks.  Good catch!</li>
        </ul>
        <p class="MsoNormal"> </p>
        <p>
          <span class="fontstyle0"><span>Figure 5-8: Combination of
              Internet and CCSDS Protocols</span></span><span>  appears
            to be missing. </span></p>
        <ul type="disc">
          <li class="MsoListParagraph"><b>Response</b>: The figure 5-8
            caption should have been removed because the figure had been
            removed.
          </li>
        </ul>
        <p class="MsoNormal"> </p>
        <br>
        <p class="MsoNormal">Do these responses allay your
          concerns/issues?</p>
         
        <p class="MsoNormal">Regards</p>
        <p class="MsoNormal"> </p>
        <p class="MsoNormal">howie</p>
        <p class="MsoNormal">----------</p>
        <p class="MsoNormal"><b><span>Howard Weiss</span></b><b><span>,
            </span></b><b><span>CISSP</span></b><b><span></span></b></p>
        <p class="MsoNormal"><b><span>PARSONS, Inc.</span></b></p>
        <p class="MsoNormal"><span>7110 Samuel Morse Dr</span></p>
        <p class="MsoNormal"><span>Suite 200</span></p>
        <p class="MsoNormal"><span>Columbia, MD 21046</span></p>
        <p class="MsoNormal"><span>443-430-8089 (office)</span></p>
        <p class="MsoNormal"><span>443-494-9087 (cell)</span></p>
        <p class="MsoNormal"><span>443-430-8238 (fax)</span></p>
        <p class="MsoNormal"> </p>
      </div>
      <br>
      <div>NOTICE: This email message and all attachments transmitted
        with it may contain privileged and confidential information, and
        information that is protected by, and proprietary to, Parsons
        Corporation, and is intended solely for the use of the addressee
        for the specific purpose set forth in this communication. If the
        reader of this message is not the intended recipient, you are
        hereby notified that any reading, dissemination, distribution,
        copying, or other use of this message or its attachments is
        strictly prohibited, and you should delete this message and all
        copies and backups thereof. The recipient may not further
        distribute or use any of the information contained herein
        without the express written authorization of the sender. If you
        have received this message in error, or if you have any
        questions regarding the use of the proprietary information
        contained therein, please contact the sender of this message
        immediately, and the sender will provide you with further
        instructions.</div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image0012.jpg
Type: image/jpeg
Size: 28236 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20190218/2256551e/attachment-0001.jpg>


More information about the CESG mailing list