Subject: [dtn] Position of CRC in canonical block

From: Marius Feldmann <[email-masked]>
Date: Thu, 1 Dec 2016 19:31:09 +0100

Hello,

we are currently implementing the 06 version of the BP draft.

In this context we have some issues regarding the CRC field in the canonical block. I have already referred to this aspect a couple of weeks ago, but maybe it was not fully understood.

According to the specification draft, the CRC field is located directly in front of the content of the canonical block. Thus, the CBOR serializer has to hand back the position of this field after serializing the block. I am not sure if there are better ways, but for the moment that seems to be the way to go. However, this is not really a nice solution because the used CBOR serializer has to be modified. 

This issue could be avoided if the CRC field would be placed at the end of the canonical block. This would render it possible to serialize the block and calculate the CRC "on the fly" attaching it finally to the serialized block.

Does anybody support this proposed modification?

Marius

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 2 Dec 2016 03:17:56 +0000

FWIW, I think Marius makes a good argument here; I am fine with making this change.

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Marius Feldmann [[email-masked]]
Sent: Thursday, December 01, 2016 10:31 AM
To: [email-masked]
Subject: [dtn] Position of CRC in canonical block

Hello,

Marius

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: Rick Taylor <[email-masked]>
Date: Fri, 2 Dec 2016 11:11:18 +0000

Scott, Marius,

Is it worth checking to see what the COSE (CBOR object signing and embedding) WG are doing?  They may have a solution we can reuse?

Rick

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: 02 December 2016 03:18
To: Marius Feldmann; [email-masked]
Subject: Re: [dtn] Position of CRC in canonical block

Scott

Hello,

Marius

---

From: Brian Sipos <[email-masked]>
Date: Sun, 4 Dec 2016 16:28:02 +0000

Some additional points about the checksums that I overlooked in my earlier CBOR coments and that relate to Marius' comment:

 - For the sake of computing the CRC in a consistent way, I think the CRC value needs be defined as a CBOR byte-string instead of CBOR integer. When encoding as an integer there is an ambiguity about what the encoded form is and the current bpbis-06 requirement that the CRC "...SHALL be temporarily populated with the value zero." A naive encoder may shorten the "value zero" integer as the single-octet short form 0x00 rather than an expanded form (0x190000 for 16-bit or 0x1a00000000 for 32-bit). Using a byte-string encoding would guarantee that all encoders are producing the same exact same form (0x420000 for 16-bit and 0x4400000000 for 32-bit).

 - I think it would be helpful to have a note about how to handle the case where the block-being-checksummed is encoded as indefinite-length CBOR array form (where the block ends in a "break" 0xFF octet). Is the checksum supposed to include the break octet? I think the answer is yes but it may be useful to actually state this.

 - Can you add explicit Normative References to specs that define the checksums (CRC-16 and CRC-32)? I know that this may be "common knowledge" but I would feel better having a document to point to which defines the checksum (and may have some test vectors as a bonus). Are these the same as the ITU-T V.42 checksums? It looks like the 32-bit is but 16-bit is not.

________________________________
From: dtn <[email-masked]> on behalf of Marius Feldmann <[email-masked]>
Sent: Thursday, December 1, 2016 1:31:09 PM
To: [email-masked]
Subject: [dtn] Position of CRC in canonical block

Hello,

Marius

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sun, 4 Dec 2016 16:30:34 +0000

I am fine with all these changes.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Brian Sipos
Sent: Sunday, December 4, 2016 8:28 AM
To: [email-masked]
Subject: Re: [dtn] Position of CRC in canonical block

________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Marius Feldmann <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 1, 2016 1:31:09 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn] Position of CRC in canonical block

Hello,

Marius

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 5 Dec 2016 18:54:42 +0000

On a cursory glance at COSE, I think it looks a little bit heavyweight for our purposes.  COSE defines security messages, each of which is a CBOR array of at least 3 elements, and it seems designed for keyed authentication and encryption; there's no mention of CRCs or checksums anywhere in draft-ietf-cose-msg-24.  But for our purposes a CRC is all that's needed; authentication and encryption are defined in bpsec.  So I'm skeptical.

Scott

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: Friday, December 2, 2016 3:11 AM
To: Burleigh, Scott C (312B) <[email-masked]>; Marius Feldmann <[email-masked]>; [email-masked]
Subject: RE: [dtn] Position of CRC in canonical block

Scott, Marius,

Rick

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: 02 December 2016 03:18
To: Marius Feldmann; [email-masked]
Subject: Re: [dtn] Position of CRC in canonical block

Scott

Hello,

Marius