[Sis-dtn] [EXT] SIS-DTN Meeting tomrrow: discuss BPsec

Mehmet Adalier madalier at antarateknik.com
Wed Feb 22 22:44:34 UTC 2023


I definitely agree with Sarah that Option 1 is the way to go.

 

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of "Heiner, Sarah E. via SIS-DTN" <sis-dtn at mailman.ccsds.org>
Reply-To: "Heiner, Sarah E." <Sarah.Heiner at jhuapl.edu>
Date: Wednesday, February 22, 2023 at 7:26 AM
To: Keith Scott <keithlscott at gmail.com>, "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] [EXT] SIS-DTN Meeting tomrrow: discuss BPsec

 

Hi Keith,

 

I agree with your summary here for moving forward with security contexts (option 1). The IETF BPSec Default Security Contexts are (intentionally) limited in what they support, making them useful for interoperability testing, but will also require the definition of CCSDS-specific security contexts to enable other use cases. Defining these CCSDS-specific security contexts outside of the BPSec book sounds like the right way to proceed. 

 

I have the original figures for the book and will drop them in the Google Drive BPSec folder this morning. 

 

Thanks,

Sarah

 

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of Keith Scott via SIS-DTN <sis-dtn at mailman.ccsds.org>
Reply-To: Keith Scott <keithlscott at gmail.com>
Date: Wednesday, February 22, 2023 at 9:41 AM
To: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Subject: [EXT] [Sis-dtn] SIS-DTN Meeting tomrrow: discuss BPsec

 

APL external email warning: Verify sender sis-dtn-bounces at mailman.ccsds.org before clicking links or attachments

 

OK, in collecting BPsec information to try to get a resolution to Tomaso I think we're not there yet.

 

I think the largest outstanding item is Annex D where we tried to profile the IETF default security contexts.  I think that if we profile in changes to e.g. the key lengths as Mehmet suggests, that would define a NEW security context that we'd need to register w/ IANA.  So I think our options are:

 

1. Remove annex D and simply reference the IETF default security contexts; define CCSDS-specific security contexts in TBD new documents.

 

2. Proceed with a profile as in annex D and use that to register NEW security contexts with IANA (essentially the existing IANA ones with our profile changes).

 

3. Work to define new CCSDS security contexts, replace Annex D with those, and use it to register the new contexts w/ IANA.

 

I KNOW we talked about this, but I'm having difficulty getting at my older notes at the moment.  I THINK we opted for option 1.

 

 

And we need to go over Annex A (PICS).

 

 

 

Also, does anybody (APL?) have the original art for the figures in the book?  If not we'll have to recreate them.

 

  --keith

 

_______________________________________________ SIS-DTN mailing list SIS-DTN at mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230222/45ef3995/attachment-0001.htm>


More information about the SIS-DTN mailing list