Re: [dtn] [EXT] Re: IPN update text-form and CBOR-form parity with allocator zero

[Rick Taylor <[e-mail]>]

I’ve been mulling this over, and I think I’m going back on my previous comment.

The *canonical* text representation must be unique (by definition), and shortest (by design), and therefore I don’t like allowing ‘ipn:0.X.Y’ as a valid canonical representation.  Of course a generous parser might allow “ipn:00000.0000001.0000003” to map to “ipn:1.3”, but I do think the canonical representation should be to drop the 0 if the allocator id is zero.

I will double check appendix A, but surely with any process that creates cryptographic hashes over text, the expectation/specification is that the text is in canonical format?

@Brian – I’m not convinced that a CBOR->Text->CBOR will lose information:  If the allocator_id is not present, then it is treated as 0, so although 0 is not emitted, it is clear from the overall format that it is implicitly 0.  Much as I would like to make trivial transcoders more trivial, I’m not sure it’s a design goal that outweighs brevity of representation or uniqueness.

Cheers,

Rick

From: Birrane, Edward J. [mailto:[e-mail]]
Sent: 07 April 2024 14:09
To: Rick Taylor; Brian Sipos; [e-mail]
Subject: RE: [EXT] Re: [dtn] IPN update text-form and CBOR-form parity with allocator zero

Rick,

  My read on this is that the decisions around how we textually represent the default allocator and encode them in the 2 and 3 element case are all fine as-is. No changes to sections 4 or 6 or appendices b or d are needed.

  I think there is a typo in appendix a which Brian found and needs to be corrected. Appendix a needs to allow a zero allocator id to be compliant with the text in the rest of the document.

-Ed

Sent with BlackBerry Work
(www.blackberry.com)

From: dtn <[e-mail]<mailto:[e-mail]>> on behalf of: Rick Taylor <[e-mail]<mailto:[e-mail]>>
Date: Sunday, Apr 07, 2024 at 6:58 AM
To: Brian Sipos <[e-mail]<mailto:[e-mail]>>, [e-mail] <[e-mail]<mailto:[e-mail]>>
Subject: [EXT] Re: [dtn] IPN update text-form and CBOR-form parity with allocator zero

APL external email warning: Verify sender [e-mail] before clicking links or attachments



Thanks Brian,

A good comment.  We prevaricated about whether the leading ‘0’ for the Default Allocator was permissible in the text representation, or whether it MUST be omitted.  It sounds like we went with the wrong choice.

I’ll have a good look at the impact of relaxing the MUST to SHOULD, but it sounds like the right way to go in light of your comments.

Update incoming ASAP.

Cheers,

Rick

From: dtn [mailto:[e-mail]] On Behalf Of Brian Sipos
Sent: 06 April 2024 23:13
To: [e-mail]
Subject: [dtn] IPN update text-form and CBOR-form parity with allocator zero

Authors of ipn-update draft,
There is a nuance to the text form specified in Appendix A [1] that prohibits a zero-valued allocator component so that the zero-allocator can only be represented by the two-component text form. This is in contrast to the CDDL definition in Appendix C which does allow a zero-valued allocator component.

A side-effect of this is that there is not a one-to-one correspondence between text-form and CBOR-form EIDs. Certainly the semantic meaning is the same between a zero-allocator three-component form and the two-component form, but the lack of exact correspondence means that a trivial transcoder needs to have some special cases for this situation. This can be seen in the discrepancy between EIDs present in Appendix B.1 vs. D.1 and B.3 vs. D.3. It also means that not all IPN-scheme EIDs can be written in a three-component canonical form.

Because of this, it is possible that a CBOR-to-text-to-CBOR conversion will lose information and the output will be different than the input. This will have implications for things that require guarantees about re-encodings such as BPSec processing.

I think a simple change in Appendix A from

allocator-identifier = non-zero-number
to

allocator-identifier = number
will resolve this in a way that probably is compatible with existing three-component EID codec implementations anyway.

This also calls into question the single statement in Section 8.3; there should probably be a stronger security statement and a requirement that implementations must preserve the component count when transcoding IPN EIDs.

Apologies for this late feedback, but I think it will avoid a subtle security issue and potential user headaches.

- Brian S.

[1] https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-10.html#appendix-A