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

[Brian Sipos <[e-mail]>]

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]> 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]>
> *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]
> 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] <[e-mail]>] *On
> Behalf Of *Rick Taylor
> *Sent:* 07 April 2024 15:49
> *To:* Birrane, Edward J.; Brian Sipos; [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]
> <[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]> on behalf of: Rick Taylor <
> [e-mail]>
>
> *Date: *Sunday, Apr 07, 2024 at 6:58 AM
>
> *To: *Brian Sipos <[e-mail]>, [e-mail] <[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] <[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
>
>
>