[DNSOP] Re: [EXT] [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

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

Scott,
I see two major issues with your current proposal.

The first is that a CLA is more than just a specific transport, it is also a profile and likely a whole protocol above that transport. For example, there are multiple versions of "TCPCL" which behave differently and have different capabilities. So just saying "I support TCP-over-IPv6" falls short of indicating what a node is actually capable of and whether or not I can expect to successfully make contact and transfer bundles with that peer.

The second is that I think it's actually more appropriate to use DNS Service Discovery (DNS-SD) as a mechanism to register CLAs over DNS. I have drafted a profile of this in [1] which does not even require any new code point allocations; the existing DNS-SD and service name registries [2] already have what is needed for a node to register listening CLAs as services. The DNS-SD also works for both unicast and multicast DNS. In the specific profile of [1] there is a requirement that only BP routers register themselves, but that is more of a convenience than a strict necessity.

One possible extension to the DNS-SD profile is to define a service parameter ("bpnodeid" or similar) which would allow exposing the node's administrative EID in the DNS-SD registration. This opens the door to some security considerations about authenticating ownership of that EID, but it is a possible mechanism on a closed and trusted network.

Another possibility is to use existing CERT RR [3] to store certificates asserting ownership of one or more EIDs, which are already defined as a PKIX profile in RFC 9174 [4]. My main concern with just having a bare EID (or part of an EID in this case, just the IPN node number) in DNS is that there is no way to assign a chain of trust to some authority of BP node naming.

Thanks for consideration of this feedback,
Brian S.

[1] https://www.ietf.org/archive/id/draft-sipos-dtn-edge-zeroconf-01.html#section-3
[2] https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
[3] https://www.rfc-editor.org/rfc/rfc4398.html
[4] https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.2

> -----Original Message-----
> From: Scott Johnson <[e-mail]>
> Sent: Tuesday, June 25, 2024 5:57 AM
> To: Erik Kline <[e-mail]>
> Cc: dnsop <[e-mail]>; [e-mail]; [e-mail]
> Subject: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
> Protocol RFC9171
> 
> APL external email warning: Verify sender [e-mail] before
> clicking links or attachments
> 
> Hi Erik,
> 
> Cross posted to DTN list for any such discussion, if they so desire.
> The draft in question is here:
> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> 
> Thanks,
> ScottJ
> 
> On Tue, 25 Jun 2024, Erik Kline wrote:
> 
> > Speaking as the responsible AD for DTN, I think the DTN working group
> > should probably have a discussion about what it wants to do (if
> > anything) vis. DNS RRs.
> >
> > On Tue, Jun 25, 2024 at 08:27 Scott Johnson <[e-mail]>
> > wrote:
> >       Hi Mark,
> >
> >       On Tue, 25 Jun 2024, Mark Andrews wrote:
> >
> >       >
> >       >
> >       >> On 25 Jun 2024, at 16:36, Scott Johnson
> >       <[e-mail]> wrote:
> >       >>
> >       >> Hi Mark,
> >       >>
> >       >> Noted and changed.  Good stuff, thanks.  Updated draft
> >       (04) at datatracker using that verbiage:
> >       >>
> >       https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >       >>
> >       >> Is it appropriate to add an acknowledgments section or
> >       co-authors at this point?
> >       >
> >       > I’m not fussed either way.
> >
> >       (05) of the draft adds a "Contributors" section.
> >
> >       >
> >       >> As well, should I be asking for WG adoption (DNSOP or
> >       DTN WG), or as an Informational document, is Individual
> >       submission sufficient?
> >       >
> >       > I’ll leave that for the chairs to answer.
> >
> >       Ack.  Thank you so much for your time and attention to this
> >       document.
> >
> >       ScottJ
> >
> >       >
> >       >> Thanks,
> >       >> ScottJ
> >       >>
> >       >>
> >       >> On Tue, 25 Jun 2024, Mark Andrews wrote:
> >       >>
> >       >>> Made the IPN description more specific.
> >       >>>
> >       >>>
> >       >>>                                           Wire format
> >       encoding shall
> >       >>> be an unsigned 64-bit integer in network order.
> >       Presentation format, for these
> >       >>> resource records are either a 64 bit unsigned decimal
> >       integer, or two 32 bit
> >       >>> unsigned decimal integers delimited by a period with
> >       the most significant 32 bits
> >       >>> first and least significant 32 bits last.  Values are
> >       not to be zero padded.
> >       >>>
> >       >>>> On 25 Jun 2024, at 15:22, Scott Johnson
> >       <[e-mail]> wrote:
> >       >>>>
> >       >>>> Hi Scott,
> >       >>>>
> >       >>>> Wire format of 64 bit unsigned integer it is for IPN.
> >       >>>> Updated draft (03) incorporating all changes posted
> >       at:
> >       >>>>
> >       https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >       >>>>
> >       >>>> Let me know if you see anything else, Mark, and
> >       thanks!
> >       >>>>
> >       >>>>
> >       >>>> ScottJ
> >       >>>>
> >       >>>>
> >       >>>> On Mon, 24 Jun 2024, [e-mail] wrote:
> >       >>>>
> >       >>>>> I've lost lock on the ipn-scheme RFC, but my own
> >       assessment is that always sending a single 64-bit unsigned
> >       integer would be fine.  The application receiving the
> >       resource can figure out whether or not it wants to condense
> >       the value by representing it as two 32-bit integers in
> >       ASCII with leading zeroes suppressed and a period between
> >       the two. Internally it's always going to be a
> >       64-bitunsigned integer, from which a 32-bit "allocator"
> >       number can be obtained by simply shifting 32 bits to the
> >       right; if the result is zero then we're looking at an
> >       old-style IPN node number.
> >       >>>>>
> >       >>>>> Scott
> >       >>>>>
> >       >>>>> -----Original Message-----
> >       >>>>> From: Scott Johnson <[e-mail]>
> >       >>>>> Sent: Monday, June 24, 2024 8:26 PM
> >       >>>>> To: Mark Andrews <[e-mail]>;
> >       [e-mail]
> >       >>>>> Cc: dnsop <[e-mail]>
> >       >>>>> Subject: Re: [DNSOP] IPN and CLA RRTYPEs to support
> >       Bundle Protocol RFC9171
> >       >>>>>
> >       >>>>> Hi Mark,
> >       >>>>>
> >       >>>>>
> >       >>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
> >       >>>>>
> >       >>>>>>
> >       >>>>>>
> >       >>>>>>> On 25 Jun 2024, at 10:32, Scott Johnson
> >       <[e-mail]> wrote:
> >       >>>>>>>
> >       >>>>>>> Hi Mark,
> >       >>>>>>>
> >       >>>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
> >       >>>>>>>
> >       >>>>>>>> An obvious correction “LTP--v6” -> “LTP-v6”
> >       >>>>>>>
> >       >>>>>>> Aha!  Good eye.
> >       >>>>>>>
> >       >>>>>>>>
> >       >>>>>>>> For IPN why isn’t the wire format two network 64
> >       bit integers?  That is 16 bytes.  Also 2^64-1 is 20
> >       characters so 2 64-bit numbers separated by “." is 41
> >       characters.  It’s not clear where then 21 comes from.
> >       >>>>>>>
> >       >>>>>>> EID is the basic unit of IPN naming, which is
> >       indeed two 64 bit integers separated by a ".". We are
> >       seeking to represent only the node-nbr component of an EID,
> >       as the service-nbr component is loosely analagous to a UDP
> >       or TCP port, for which there is one publicly defined
> >       service in the registry, and a collection of space agencies
> >       who lay claim to another chunk of them:
> >       >>>>>>>
> >       https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service-
> num
> >       >>>>>>> bers As such, there is no gain in including the
> >       second 64-bit
> >       >>>>>>> integer, representing service-nbr in the DNS
> >       records, and indeed, a loss of utility on the application
> >       level.
> >       >>>>>>>
> >       >>>>>>> The node-nbr component is presently, under RFC7116,
> >       a 64 bit unsigned integer.  There is a draft from the DTN
> >       WG currently making it's way through the IESG which will
> >       amend the IPN naming scheme. Perhaps I should add it to
> >       normative references?
> >       >>>>>>>
> >       https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/
> >       >>>>>>>
> >       >>>>>>> In effect it splits the node-nbr component into
> >       two-32 bit integers; Allocator Identifier and Node Number
> >       in the "Three-Element Scheme-Specific Encoding" of Section
> >       6.1.2 over the above.  Section 6.1.1 describes the
> >       "Two-Element Scheme-Specific Encoding" method which retains
> >       the use of a single 64-bit integer.  Thus, a single 64 bit
> >       integer (20 characters) or two 32-bit integers (10
> >       characters each) delimited by a "."
> >       >>>>>>> makes 21 characters maximum.  This preserves
> >       forwards compatibility with the proposed amended scheme,
> >       and does no harm if the scheme fails to achieve
> >       standardization.
> >       >>>>>>
> >       >>>>>> Or just 8 bytes on the wire with both possible input
> >       formats described.
> >       >>>>>> Machines using the records will just be converting
> >       ASCII values to a
> >       >>>>>> 64 bit integer.  We may as well transmit it as
> >       that.  Input validation
> >       >>>>>> will need to do the conversion anyway to ensure both
> >       fields will fit
> >       >>>>>> into 32 bits in the “.” separated case and 64 bits
> >       in the single value case.
> >       >>>>>> Length along is not sufficient to prevent undetected
> >       overflows.  The
> >       >>>>>> only thing you need to determine is which format is
> >       the initial
> >       >>>>>> canonical presentation format.  That can be changed
> >       with a later
> >       >>>>>> update if needed.
> >       >>>>>
> >       >>>>> I am tagging in Scott Burleigh, co-author of RFC9171
> >       on this point for clarification.
> >       >>>>> Section 4.2.5.1.2 of same indicates:
> >       >>>>>
> >       >>>>> "Encoding considerations:
> >       >>>>> For transmission as a BP endpoint ID, the
> >       scheme-specific part of a URI of the ipn scheme SHALL be
> >       represented as a CBOR array comprising two items. The first
> >       item of this array SHALL be the EID's node number (a number
> >       that identifies the node) represented as a CBOR unsigned
> >       integer.
> >       >>>>> The second item of this array SHALL be the EID's
> >       service number (a number that identifies some application
> >       service) represented as a CBOR unsigned integer. For all
> >       other purposes, URIs of the ipn scheme are encoded
> >       exclusively in US-ASCII characters."
> >       >>>>>
> >       >>>>> Having already established that we are transmitting
> >       the node-nbr component only, and not a full EID, I am not
> >       sure we are restricted to using only US-ASCII.  ScottB,
> >       your opinion?  CBOR might also be an option, but that would
> >       place a higher burden upon implementers, I think.  Integer
> >       notation for wire format is fine by me.
> >       >>>>>
> >       >>>>>>
> >       >>>>>>>> Limit CLA characters to Letter Digit Hyphen rather
> >       than the full ASCII range.
> >       >>>>>>>
> >       >>>>>>> It is possible for a node to support multiple CLAs
> >       on the same IP
> >       >>>>>>> address and node number.  Will this change allow
> >       multiple, comma
> >       >>>>>>> delimited values to be expressed in the CLA
> >       record?  If so, can you
> >       >>>>>>> point me to an example so I can get the verbiage of
> >       the draft right?
> >       >>>>>>> If not, what do you recommend (in addition to my
> >       defining that in the
> >       >>>>>>> draft)?  I like the idea of limiting the usable
> >       characters.
> >       >>>>>>
> >       >>>>>> Personally I would just use a TXT record wire format
> >       with the
> >       >>>>>> additional constraint that the values are restricted
> >       to Letter, Digits
> >       >>>>>> and interior Hyphens.  The input format matches the
> >       TXT record with
> >       >>>>>> the above character value constraints.  The
> >       canonical presentation
> >       >>>>>> form is space separated, unquoted, unescaped ASCII.
> >       This allow for
> >       >>>>>> long records to be split over multiple lines.
> >       Descriptive comments in the zone file.
> >       >>>>>> This take one extra octet over using comma separated
> >       values.
> >       >>>>>
> >       >>>>> Sold to the man from ISC :)  This part works great;
> >       thank you!  Updated draft pushed to datatracker at
> >       https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >       >>>>>
> >       >>>>> Thanks,
> >       >>>>> Scott
> >       >>>>>
> >       >>>>>
> >       >>>>>>
> >       >>>>>> e.g.
> >       >>>>>>
> >       >>>>>> example inputs
> >       >>>>>>
> >       >>>>>> @ CLA ( TCP-V4 ; TCP over IPv4
> >       >>>>>>    TCP-V6 ) ; TCP over IPv6
> >       >>>>>>
> >       >>>>>> @ CLA “TCP-V4” TCP-V6
> >       >>>>>>
> >       >>>>>> Wire
> >       >>>>>>
> >       >>>>>> 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ ‘4’ 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’
> >       ‘6’
> >       >>>>>>
> >       >>>>>> Canonical presentation
> >       >>>>>>
> >       >>>>>> @ CLA TCP-V4 TCP-V6
> >       >>>>>>
> >       >>>>>>
> >       >>>>>>> Thanks,
> >       >>>>>>> Scott
> >       >>>>>>>
> >       >>>>>>>>
> >       >>>>>>>> Mark
> >       >>>>>>>>
> >       >>>>>>>>> On 25 Jun 2024, at 08:19, Scott Johnson
> >       <[e-mail]> wrote:
> >       >>>>>>>>>
> >       >>>>>>>>> Hi All,
> >       >>>>>>>>>
> >       >>>>>>>>> After reading the recent discussion about WALLET,
> >       I am hesitant to jump into the fray here, but this plainly
> >       is the correct group to help me get my logic and syntax
> >       right, so here goes:
> >       >>>>>>>>>
> >       >>>>>>>>> I submitted requests to IANA for IPN and CLA
> >       RRTYPEs, these representing the missing datasets necessary
> >       to make a BP overlay network connection from data found by
> >       DNS queries.
> >       >>>>>>>>>
> >       >>>>>>>>> For those not familiar, BP is a store and forward
> >       mechanism generally used in high latency situations where
> >       there does not exist constant end-to-end connectivity.  It
> >       was designed for deep space networking, however has network
> >       segments and application uses which overlay the terrestrial
> >       Internet.  There will arise similar use cases on the Moon
> >       (in the reasonably near future) and Mars whereby low
> >       latency, constant connectivity exists, thereby making use
> >       of DNS in these situations viable.
> >       >>>>>>>>>
> >       >>>>>>>>> My Expert Reviewer asked for an i-d, to clarify
> >       the requests, and that said i-d be sent to this list for
> >       review.
> >       >>>>>>>>>
> >       >>>>>>>>> Please find the approptiate draft here:
> >       >>>>>>>>>
> >       https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >       >>>>>>>>>
> >       >>>>>>>>> Relevant IANA requests:
> >       >>>>>>>>>
> >       https://tools.iana.org/public-view/viewticket/1364843
> >       >>>>>>>>>
> >       https://tools.iana.org/public-view/viewticket/1364844
> >       >>>>>>>>>
> >       >>>>>>>>> I have the BP community also reviewing this, but
> >       they are generally in agreement as to use.
> >       >>>>>>>>>
> >       >>>>>>>>> Thanks,
> >       >>>>>>>>> Scott M. Johnson
> >       >>>>>>>>> Spacely Packets, LLC
> >       >>>>>>>>>
> >       >>>>>>>>> _______________________________________________
> >       >>>>>>>>> DNSOP mailing list -- [e-mail] To
> >       unsubscribe send an email
> >       >>>>>>>>> to [e-mail]
> >       >>>>>>>>
> >       >>>>>>>> --
> >       >>>>>>>> Mark Andrews, ISC
> >       >>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >       >>>>>>>> PHONE: [phone]              INTERNET:
> >       [e-mail]
> >       >>>>>>>>
> >       >>>>>>>> _______________________________________________
> >       >>>>>>>> DNSOP mailing list -- [e-mail] To
> >       unsubscribe send an email to
> >       >>>>>>>> [e-mail]
> >       >>>>>>
> >       >>>>>>
> >       >>>>>> --
> >       >>>>>> Mark Andrews, ISC
> >       >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >       >>>>>> PHONE: [phone]              INTERNET:
> >       [e-mail]
> >       >>>>>>
> >       >>>>>>
> >       >>>>>
> >       >>>>> _______________________________________________
> >       >>>>> DNSOP mailing list -- [e-mail]
> >       >>>>> To unsubscribe send an email to [e-mail]
> >       >>>
> >       >>>
> >       >>> --
> >       >>> Mark Andrews, ISC
> >       >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >       >>> PHONE: [phone]              INTERNET:
> >       [e-mail]
> >       >>>
> >       >>> _______________________________________________
> >       >>> DNSOP mailing list -- [e-mail]
> >       >>> To unsubscribe send an email to [e-mail]
> >       >
> >       >
> >       > --
> >       > Mark Andrews, ISC
> >       > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >       > PHONE: [phone]              INTERNET:
> >       [e-mail]
> >       >
> >       > _______________________________________________
> >       > DNSOP mailing list -- [e-mail]
> >       > To unsubscribe send an email to
> >       dnsop-
> [e-mail]_______________________________________________
> >       DNSOP mailing list -- [e-mail]
> >       To unsubscribe send an email to [e-mail]
> >
> >
> >