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

[Rick Taylor <[e-mail]>]

Brian,

I take your point that sending reports back to a sender that is using the 2-element CBOR encoding, using the 3-element CBOR encoding will cause problems.

However, I think the solution here is to extend section 8.3 of the Security Considerations section to state something like: “When sending reports back to a source that uses the 2-element encoding, the 2-element encoding MUST be used.  The assumption being that the sender does not support the 3-element encoding, and therefore using that format in status reports will prevent correct processing.”  This isn’t particularly onerous on implementations – the assumption being that either they can a) remember the original encoding, or b) use the exact octets in the bundle which they must still have if they are reporting on it.

Ed and I are both loathe to place strictures on the encodings that will prevent a smooth transition to the (generally more efficient) 3-element encoding by implementations.

Would that change address your issue?

Rick

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

Ed,
I agree with most of what you have said, especially the text in your point #3. My issue is that it assumes that an intermediate processor of an EID actually has a free choice to make, but I think that's an incorrect assumption. The originator of an EID certainly can choose the 2- or 3-component form at-will, that I see no problem with. But I think intermediate processing of that EID (either on the same node or any other node) does not have a choice in which form to use. There are a few reasons why changing the form will cause problems:

A. If I create a bundle with a Source of ipn:4294967298.3 then I shouldn't be getting status reports having a Source Node ID of ipn:1.2.3 (maybe I can't process these, I chose the original form for a reason)
B. If I create a bundle with a Report-To of ipn:4294967298.3 then other nodes shouldn't be sending status reports to ipn:1.2.3
C. If an intermediate node chooses a different form of either three EIDs from the primary block when processing security block targets or AADs this will break things badly. The current stance of "you probably shouldn't break security" is weaker than having requirements such that "if you follow the rules you won't break security."

My thesis here is that the information model from Section 3 leaves out the choice of encoding form and that when processing EIDs that original form needs to be kept intact to avoid causing problems; especially in middleboxes where there is no other information about why either form would be preferable for any specific bundle. I understand that the different forms are logically equivalent, but there are aspects of EID processing that don't (and shouldn't) care about logical equivalence; they only care about encoded form.

As a secondary concern, giving intermediate processing a choice of form will lead to confusion when troubleshooting if the on-the-wire EID uses one form while the logging or diagnostic info chooses to map to the other form. Having the original encoding form be part of the EID information will remove that ambiguity and keep diagnostics more consistent with the actual traffic (when the logs are complaining about "ipn:1.2.3" but that appears nowhere in the actual traffic it will be confusing and frustrating). This is also why I think having one-to-one parity between text and CBOR forms is important generally.

On Sun, Apr 7, 2024 at 12:14 PM Birrane, Edward J. <[e-mail]<mailto:[e-mail]>> wrote:
(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]<mailto:[e-mail]>>
Sent: Sunday, April 7, 2024 10:55 AM
To: Rick Taylor <[e-mail]<mailto:[e-mail]>>; Birrane, Edward J. <[e-mail]<mailto:[e-mail]>>; Brian Sipos <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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