[Sis-dtn] [EXT] Canonical CBOR in BPv7 a MUST for block field encoding?

Thu Dec 2 15:52:21 UTC 2021

The IETF language should be “MUST” in this instance (and not must). 

The encoding (and perhaps at-waypoint transcoding) needs to be deterministic. I think that option 3 below has to be avoided, but opening up block fields to a variety of encodings might not be the best way to prevent that.

Consider the case where one BPA adds a block with a fixed 64-bit block type. And then, another BPA (at a waypoint) adds a new block to the bundle (which is allowed) but does so with a fixed-width 32-bit block type, and yet another BPA adds another block to the bundle with an 8-bit block type. At a bundle destination, some logic would still need to understand the widths of these fields. For example, if the bundle destination in this case were to be firmware that expects a fixed 32-bit field for block type, the aforementioned bundle would break that implementation.  

I think we should avoid that and have individual BPAs condition data going into and out-of FPGAs. 

-Ed

Edward J. Birrane, III, Ph.D. (he/him/his)

Chief Engineer, Space Constellation Networking

Space Exploration Sector

Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (C) 443-690-8272

From: Dr. Keith L Scott <kscott at mitre.org> 
Sent: Thursday, December 2, 2021 10:21 AM
To: Felix.Flentge at esa.int; Birrane, Edward J. <Edward.Birrane at jhuapl.edu>
Cc: Scott Burleigh <scott.c.burleigh at jpl.nasa.gov>; sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXT] Canonical CBOR in BPv7 a MUST for block field encoding?

I *think* the issue here is going to be:

IF somebody wants to implement BPv7 in hardware, they might want ‘known-sized’ fields (akin to the field set selector we’re working towards in LTP – an identifier that a receiver can use as a key to look up the field lengths in the rest of a bundle).  If somebody DOES want that as a way to facilitate high-speed hardware implementations, and if the IETF text becomes a MUST (not a must) then we’ll have your option3 below.

                                --keith

From: Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int>  <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >
Date: Thursday, December 2, 2021 at 1:59 AM
To: Birrane, Edward J. <Edward.Birrane at jhuapl.edu <mailto:Edward.Birrane at jhuapl.edu> >
Cc: Dr. Keith L Scott <kscott at mitre.org <mailto:kscott at mitre.org> >, Scott Burleigh <scott.c.burleigh at jpl.nasa.gov <mailto:scott.c.burleigh at jpl.nasa.gov> >, sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org>  <sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> >
Subject: Re: [Sis-dtn] [EXT] Canonical CBOR in BPv7 a MUST for block field encoding?

Well, 

I think the point here is whether it is 'must' or 'MUST'. 

Is there any intention to keep some flexibility for IETF DTN here or not? 

It's an important point for (efficient) on-board implementations. CCSDS should be very clear on CBOR serialisation. So, I see four options 

1) IETF has a MUST, CCSDS confirms this MUST 
2) IETF has a 'must'--> CCSDS makes is a MUST 
3) IETF has a MUST --> CCSDS decides to implement a different serialisation (to guarantee fixed block sizes independent from actual values) 
4) IETF has a 'must'--> CCSDS decides to implement a different serialisation 

Clearly, 3)  needs to avoided and I would hope that we do not need to go to 4) ( the initial feedback is that deterministic CBOR is ok for on-board implementations, TBC). 
Ideally, we would have 1) but in order to avoid 3) we might want to stay with 1) 

On the indefinite-length exception, I'm not sure. I think the requirement for deterministic CBOR is on the blocks/fields and not the entire bundle (which is currently the only indefinite length item). 
So, we might allow indefinite-length also in blocks (which may lead to slightly more efficient encoding but might make decoding slightly more difficult). In this case, we might want to extend the deterministic CBOR requirement (with the exception) to the whole bundle. 
Or we might not allow in-definite length for blocks/fields and state explicitly that this does not apply to the full bundle. 

(I do hope, I have not been to confusing. It's still quite early for me.) 

Regards, 
Felix 

From:        "Birrane, Edward J." <Edward.Birrane at jhuapl.edu <mailto:Edward.Birrane at jhuapl.edu> > 
To:        "Dr. Keith L Scott" <kscott at mitre.org <mailto:kscott at mitre.org> >, "Scott Burleigh" <scott.c.burleigh at jpl.nasa.gov <mailto:scott.c.burleigh at jpl.nasa.gov> > 
Cc:        "sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> " <sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> > 
Date:        01/12/2021 21:30 
Subject:        Re: [Sis-dtn] [EXT] Canonical CBOR in BPv7 a MUST for block field encoding? 
Sent by:        "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org <mailto:sis-dtn-bounces at mailman.ccsds.org> > 

  _____  

I believe this is changed to deterministic CBOR with the exception the indefinite length items are not prohibited. 

Sent with BlackBerry Work
(www.blackberry.com) 

From: Dr. Keith L Scott < <mailto:kscott at mitre.org> kscott at mitre.org> 
Date: Wednesday, Dec 01, 2021, 12:01 PM 
To: Scott Burleigh < <mailto:scott.c.burleigh at jpl.nasa.gov> scott.c.burleigh at jpl.nasa.gov>, Birrane, Edward J. < <mailto:Edward.Birrane at jhuapl.edu> Edward.Birrane at jhuapl.edu> 
Cc: sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org>  < <mailto:sis-dtn at mailman.ccsds.org> sis-dtn at mailman.ccsds.org> 
Subject: [EXT] Canonical CBOR in BPv7 a MUST for block field encoding? 

APL external email warning: Verify sender kscott at mitre.org <mailto:kscott at mitre.org>  before clicking links or attachments

The draft-31 spec says:

Cryptographic verification of a block is possible only if the 
   sequence of octets on which the verifying node computes its hash - 
   the canonicalized representation of the block - is identical to the 
   sequence of octets on which the hash declared for that block was 
   computed.  To ensure that blocks are always in canonical 
   representation when they are transmitted and received, the CBOR 
   representations of the values of all fields in all blocks must 
   conform to the rules for Canonical CBOR as specified in [ <https://datatracker.ietf.org/doc/html/rfc8949> RFC8949]. 

Note the non-capitalization of the MUST requirement.  Was that intended to be capitalized (and is it in the version that the RFC editor sent back)?  What are folks thoughts on capitalizing it as part of AUTH48?

                                v/r,

                                --keith

 _______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org <mailto:SIS-DTN at mailman.ccsds.org> 
 <https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn> 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/20211202/ff88ad35/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6681 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20211202/ff88ad35/attachment-0001.bin>