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

[Marc Blanchet <[e-mail]>]

> Le 25 juin 2024 à 10:29, Sipos, Brian J. <[e-mail]> a écrit :
> 
> 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.

I agree with using DNS-SD instead. I for one, also suggested that years ago.

Marc.

> 
> 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]
>>> 
>>> 
>>> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]