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

["Birrane, Edward J." <[e-mail]>]

(chair hat off, author hat on)

All,
  I retract my prior comment about an error in Appendix A (I had skipped over the fact that Appendix A defines the text syntax (not CBOR syntax).
  However, while there is not a typo in Appendix A, there is a typo in Appendix C:  “authority-number” should be “allocator-identifier”.  I think this is just a holdover from when the concept was called authority number.


@Rick:
  I admit we could propose adding that MUST, but I don’t see a benefit to it. Allowing the 3 element encoding to represent default allocator ipns is a feature, not a bug, IMO.


@Brian:

  A few points:


  1.  The fact that the text form elides the default allocator id (e.g. we never say “ipn:0.1.2”) does not mean that the default allocator id cannot be present in the 3 element encoding.  Appendix C allows for a 0 allocator-identifier (though it currently refers to it as “authority-number” which is a typo).  And Appendix D shows 0 as a valid allocator-id in the 3-element encoding. The allowance of the default allocator in the 3 element encoding is given in section 6.1.2.
  2.  There should be no “hint” in the text form as to whether to prefer the 2 or 3 element encoding.  “ipn:1.1” can be encoded in either 2 or 3 element cases.  But, “ipn:1.2.3” can also be encoded in 2 or 3 element form.  So parity in the text/encoding forms was not a goal in this specification.
  3.  CBOR->Text->CBOR round-trips would only produce different encodings if you switched encoding forms. Put another way, a TWO_ELEMENT_CBOR->Text->THREE_ELEMENT_CBOR will produce  different encoding, as will a THREE_ELEMENT_CBOR->Text->TWO_ELEMENT_CBOR.  However, a TWO_ELEMENT_CBOR->Text->TWO_ELEMENT_CBOR should produce the same encoding, as should a THREE_ELEMENT_CBOR->Text->THREE_ELEMENT_CBOR.
  4.  I agree that a non-normative clarifying statement should be added to Section 8.3 to make clear that any node which chooses to transcode between 2 vs 3 element encodings could break integrity mechanisms.

  So, if the text form of the URI does not imply a particular encoding choice, and if sticking with a single encoding choice does not alter intermediate processing of the URI, then I think the document is fine as-is.

  Am I missing something in this assessment?
-Ed

Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Networking
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (C) 443-690-8272

From: Rick Taylor <[e-mail]>
Sent: Sunday, April 7, 2024 10:55 AM
To: Rick Taylor <[e-mail]>; Birrane, Edward J. <[e-mail]>; Brian Sipos <[e-mail]>; [e-mail]
Subject: RE: [dtn] [EXT] Re: IPN update text-form and CBOR-form parity with allocator zero

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



@Brian,

I think the issue might be the non-unique canonical CBOR encoding of the 0 allocator_id

Would it clarify adjusting the 3-element CBOR encoding in Appendix C to:

ipn-ssp3 = [
  authority-number: uint .lt 4294967296 .gt 0,   <- Not sure how to format CDDL, but I mean > 0
  node-number: uint .lt 4294967296,
  service-number: uint
]

And changing the RECOMMENDED in https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-10.html#section-6.1.2-4 to MUST?

This would enforce the use of the 3-element encoding only when the allocator id is non-0?

This would preserve your CBOR->Text->CBOR round trip

From: dtn [mailto:[e-mail]] On Behalf Of Rick Taylor
Sent: 07 April 2024 15:49
To: Birrane, Edward J.; Brian Sipos; [e-mail]<mailto:[e-mail]>
Subject: Re: [dtn] [EXT] Re: IPN update text-form and CBOR-form parity with allocator zero

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]<mailto:[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<http://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]<mailto:[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]<mailto:[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]<mailto:[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