Hi Brian,

On Tue, 25 Jun 2024, Sipos, Brian J. wrote:

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.

This sounds like an implementation issue?  Notwithstanding,
given that there are pre RFC9174 versions of TCPCL in the wild which are associated with BPv6, perhaps we can just add a BP version flag to disambiguate, like I did with versions of IP.

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 result is that the CLA RRTYPE value now reads LTP-v4-v6 or TCP-v6-v7, or, in the future, perhaps QUIC-v6-v8, if such a CLA is written. The syntax would read:

<CLA protocol>-<IP Version>-<BP Version>

This still fits with the defined wire and presentation types of CLA in the draft, while addressing the issue you raised. Sound good?

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;

I do not see requesting new RRTYPEs as an undue administrative burden, so this is not much of a selling point for me. DNSOP was quite helpful in arriving at good verbiage to describe wire and presentation formats, the clarification of which was the purpose of the draft.

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.

Nothing in my draft prevents you from using this mechanism. I prefer to avoid ambiguity in parsing a TXT record (which are used for _many_ purposes), and lowering of burden upon network operators in deploying more complicated zone files/extensions to their nameservers. Both methods can co-exist without impeding each other.


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.

I would consider DNSSEC signing sufficient to ensure authenticity of a DNS record. Would you not?

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.

This is an interesting notion to use the CERT RR, but as stated, it is not a huge challenge to add relevant/useful RRTYPEs. If TCPCLv4 is already using this record, then perhaps an additional one should be created for this purpose, if DNSSEC does not provide the necessary assertation of responsibility. As I stated in my response to Rick, I see the possiblity of security context (CTX) and BPSEC public key (BSEC) records as well, in a future draft. What are your thoughts on distribution of that information through this channel?


Thanks for consideration of this feedback,

Thank you for providing it. I see my proposal as a "path of least resistance" to expedite a certain level of functionality which enables easier application development. With these RRTYPEs a user can plug a simple, standard domain name into an BP native application, which queries DNS for connection info which is passed to a BPA via an API. I see no conflict with your work in my proposal.

Sincerely,
ScottJ

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 <sc...@spacelypackets.com>
Sent: Tuesday, June 25, 2024 5:57 AM
To: Erik Kline <ek.i...@gmail.com>
Cc: dnsop <dnsop@ietf.org>; sburleig...@gmail.com; d...@ietf.org
Subject: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
Protocol RFC9171

APL external email warning: Verify sender forwardingalgori...@ietf.org 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 <sc...@spacelypackets.com>
wrote:
      Hi Mark,

      On Tue, 25 Jun 2024, Mark Andrews wrote:

     >
     >
     >> On 25 Jun 2024, at 16:36, Scott Johnson
      <sc...@spacelypackets.com> 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
      <sc...@spacelypackets.com> 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, sburleig...@gmail.com 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 <sc...@spacelypackets.com>
     >>>>> Sent: Monday, June 24, 2024 8:26 PM
     >>>>> To: Mark Andrews <ma...@isc.org>;
      sburleig...@gmail.com
     >>>>> Cc: dnsop <dnsop@ietf.org>
     >>>>> 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
      <sc...@spacelypackets.com> 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
      <sc...@spacelypackets.com> 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 -- dnsop@ietf.org To
      unsubscribe send an email
     >>>>>>>>> to dnsop-le...@ietf.org
     >>>>>>>>
     >>>>>>>> --
     >>>>>>>> Mark Andrews, ISC
     >>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
     >>>>>>>> PHONE: +61 2 9871 4742              INTERNET:
      ma...@isc.org
     >>>>>>>>
     >>>>>>>> _______________________________________________
     >>>>>>>> DNSOP mailing list -- dnsop@ietf.org To
      unsubscribe send an email to
     >>>>>>>> dnsop-le...@ietf.org
     >>>>>>
     >>>>>>
     >>>>>> --
     >>>>>> Mark Andrews, ISC
     >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
     >>>>>> PHONE: +61 2 9871 4742              INTERNET:
      ma...@isc.org
     >>>>>>
     >>>>>>
     >>>>>
     >>>>> _______________________________________________
     >>>>> DNSOP mailing list -- dnsop@ietf.org
     >>>>> To unsubscribe send an email to dnsop-le...@ietf.org
     >>>
     >>>
     >>> --
     >>> Mark Andrews, ISC
     >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
     >>> PHONE: +61 2 9871 4742              INTERNET:
      ma...@isc.org
     >>>
     >>> _______________________________________________
     >>> DNSOP mailing list -- dnsop@ietf.org
     >>> To unsubscribe send an email to dnsop-le...@ietf.org
     >
     >
     > --
     > Mark Andrews, ISC
     > 1 Seymour St., Dundas Valley, NSW 2117, Australia
     > PHONE: +61 2 9871 4742              INTERNET:
      ma...@isc.org
     >
     > _______________________________________________
     > DNSOP mailing list -- dnsop@ietf.org
     > To unsubscribe send an email to
      dnsop-
leave@ietf.org_______________________________________________
      DNSOP mailing list -- dnsop@ietf.org
      To unsubscribe send an email to dnsop-le...@ietf.org



_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to