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

["Sipos, Brian J." <[e-mail]>]

Rick,

Thank you for digging into this consideration, and I fully agree that this is not actually an IPN-specific issue at all. I just don’t want the IPN update to allow (or encourage) implementers to think that there is a choice in changing EID syntax/encoding after the originator of an EID has chosen one.

 

As really a separate topic, which is how I originally stumbled upon this, my reason for wanting to keep parity between CBOR and text URI forms of EIDs is just to avoid user confusion, and again to dispel any notion that an EID is allowed to change (in conveyed data, not in text vs. binary encoding form) during its lifetime. Things start out in text configuration, manifest as binary bundle content, and end up in text again as diagnostics and/or statistics.

 

I also have a preference that the 3-component form does allow zero-value allocators to be represented in either text/CBOR form because it simplifies processing in some cases (I can use 3-component form to represent any IPN EID) and it’s not technically “wrong” to use allocator value zero (in fact that’s how the text describes the default allocator).

 

From: Rick Taylor <[e-mail]> 
Sent: Monday, April 8, 2024 1:56 PM
To: Sipos, Brian J. <[e-mail]>; Brian Sipos <[e-mail]>; Birrane, Edward J. <[e-mail]>
Cc: [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

 

Hi Brian,

 

I have re-read [1] and I get what you mean…  there is a specification hole around handling eids in formats that aren’t recognised, when it is not required that they be parseable, as well as the transcoding issue you have highlighted.

 

My 2 cents:

*	When cloning primary block content (e.g. fragmentation, reports) then there should be specification somewhere (and I’m actually not sure the ipn draft is the only place it should exist) stating that EIDs should be maintained in the encoding format they arrived in (or actually be a memcpy of the original if possible).
*	I don’t think this applies to the ipn *text* encoding, as that is really  designed for human interaction, and not used in the BP protocol stack (though of course implementations use it).

 

I’ll chat to Ed and see if we can come up with some good text for the encodings section of the ipn update draft to cover the ‘copying’ case.

 

How does that sound?


Rick

 

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

 

Rick,

I think that these kinds of considerations are more general [1] and I don’t mean to pick on the IPN updates specifically, this is just the first situation where allowing looseness in BP processing will invite interop trouble. The key thing here is what you have stated, the assumption that a node will “remember the original encoding” but not just for status reporting. I think this applies generally when handling EIDs, and IPN scheme ones specifically in this case.

 

It’s also a consideration for things like preserving the supposed-to-be-immutable primary block. If a node chooses to change the form of an IPN EID within the primary block between receiving and sending a bundle, it will alter that block. I think the most simple solution is to just say that a node cannot make that change to an EID. Right now there just isn’t any bounding at all for an IPN-scheme EID encoder (either text or CBOR form) to steer an implementation to a specific behavior. Having a requirement that the original form is the form for that EID will lead to more consistent implementations (because someone creating an EID processor also isn’t necessarily going to be intimately familiar with all of the secondary BP-level constraints on how EIDs are used).

 

So a general requirement would be something like “When decoding and encoding IPN-scheme EIDs, to text or CBOR, the choice of 2- or 3-component form MUST be preserved from the original form.” Definitely leave implementations open to decide how to make this happen. Effectively this adds the component count as an item in the information model; just one that doesn’t affect equality comparison logic.

 

[1] https://mailarchive.ietf.org/arch/msg/dtn/rLi15ueKQy0ijzDV7DF3tBHknJs/

 

From: dtn <[e-mail] <mailto:[e-mail]> > On Behalf Of Rick Taylor
Sent: Monday, April 8, 2024 11:08 AM
To: Brian Sipos <[e-mail] <mailto:[e-mail]> >; Birrane, Edward J. <[e-mail] <mailto:[e-mail]> >
Cc: [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 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] <mailto:[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