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

"Sipos, Brian J." <Brian.Sipos@jhuapl.edu> Fri, 28 June 2024 13:42 UTC

Return-Path: <Brian.Sipos@jhuapl.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE830C14F701; Fri, 28 Jun 2024 06:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWLJXAG2T9zS; Fri, 28 Jun 2024 06:42:08 -0700 (PDT)
Received: from aplegw02.jhuapl.edu (aplegw02.jhuapl.edu [128.244.251.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FDF4C14F6EF; Fri, 28 Jun 2024 06:42:08 -0700 (PDT)
Received: from pps.filterd (aplegw02.jhuapl.edu [127.0.0.1]) by aplegw02.jhuapl.edu (8.17.1.19/8.17.1.19) with ESMTP id 45SBxZRJ027501; Fri, 28 Jun 2024 09:42:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=cc : content-type : date : from : in-reply-to : message-id : mime-version : references : subject : to; s=JHUAPLDec2018; bh=qTsFB9l67TYYrLbwKboJ5tXYYDmZikWL8UtVJOVMuls=; b=n6xWtzzOxkwHfTZ6bev52Gv1+9wIyn7z4ZS6hUxcQ+uoNFztF1FbTJI3IsuDtThKwvQ0 fC7dcrAzJEsVqs1pwh+UXeWinH8s+DjmPw34xLo5K0cGc/Akt49DsZt+BjB47Rt1Lahf d8iU2UDhq6faVbTA1BiIp6sB+CGUJIjeFPCmyqzdUQ+F4rWCk+JYK9mvZn1uXeHbuoK6 QMGPcblD90rdXDJw1TKEMjcpjG0FR8bXGb8O1WgwUHpCwCM8vICtUYHK5kETLZPcAs6D NoSLKiswAMp1flStBPCf+KIGtM1QTvZ/St0oYjvGIAO2eWJCaEjvCSdd8gWQnJu149NC sQ==
Received: from aplex25.dom1.jhuapl.edu (aplex25.dom1.jhuapl.edu [10.114.162.10]) by aplegw02.jhuapl.edu (PPS) with ESMTPS id 3ywtu1r5qk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2024 09:42:06 -0400
Received: from APLEX21.dom1.jhuapl.edu (10.114.162.6) by APLEX25.dom1.jhuapl.edu (10.114.162.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 28 Jun 2024 09:42:06 -0400
Received: from APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2]) by APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2%5]) with mapi id 15.02.1544.011; Fri, 28 Jun 2024 09:42:06 -0400
From: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>
To: Rick Taylor <rick@tropicalstormsoftware.com>, Scott Johnson <scott@spacelypackets.com>
Thread-Topic: [EXT] [dtn] Re: [DNSOP] RE: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
Thread-Index: AQHayTtfQWVC0Nh2PUKLIp2TBjh6ZbHdWnQA///G7RA=
Date: Fri, 28 Jun 2024 13:42:06 +0000
Message-ID: <61392abb5f2a4bd29a14412db45d6353@jhuapl.edu>
References: <fa28794e-d02b-aa93-56c8-082a3472c6e4@spacelypackets.com> <AC5B89B2-DD53-4A36-9B87-4136EC288851@isc.org> <2dec1732-841e-dd38-85a8-3263b1c59885@spacelypackets.com> <C363E260-22EA-43E9-97B6-D7A403C205ED@isc.org> <98976a58-b976-e82c-4b12-76edce92e691@spacelypackets.com> <CAMGpriUVcoJu1CWWLapwREN2NaHJFnVkGUpF45TJotm7uyAxyg@mail.gmail.com> <3cfc8b7c-9128-46b5-c458-ac0ebb9c79bc@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273735D06@tss-server1.home.tropicalstormsoftware.com> <b3ee82da-ae38-5781-77eb-bab292d5c113@spacelypackets.com> <cca98f92-27ee-d372-b419-81c63777033b@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273739166@tss-server1.home.tropicalstormsoftware.com> <0910E1D8-C678-498C-BAB5-AC3AA4C75750@isc.org> <e364da36-00e3-7c14-30b0-34f20b244f0a@redbarn.org> <6ff67491-30cf-cdc0-5e19-c1122465386c@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F9802737395E2@tss-server1.home.tropicalstormsoftware.com> <8b864323-a43d-3861-17e6-9f422b2d4592@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273739B7C@tss-server1.home.tropicalstormsoftware.com>
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980273739B7C@tss-server1.home.tropicalstormsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.162.19]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0211_01DAC93F.6F76CBF0"
MIME-Version: 1.0
X-CrossPremisesHeadersFilteredBySendConnector: APLEX25.dom1.jhuapl.edu
X-OrganizationHeadersPreserved: APLEX25.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-28_09,2024-06-28_01,2024-05-17_01
Message-ID-Hash: 66E3DV73PKVKKRPF25EXVQ5UGKAB7P6N
X-Message-ID-Hash: 66E3DV73PKVKKRPF25EXVQ5UGKAB7P6N
X-MailFrom: Brian.Sipos@jhuapl.edu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Erik Kline <ek.ietf@gmail.com>, dnsop <dnsop@ietf.org>, "sburleig.sb@gmail.com" <sburleig.sb@gmail.com>, "dtn@ietf.org" <dtn@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [EXT] [dtn] Re: RE: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rBRDigUDirq_cRFhmzwm4iJCJ8g>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Scott et al,
After mulling it over for a little bit, I think your CLA-visibility need might
be met by using existing per-host SRV records. For what it's worth, I had the
same logical issue with how the original IPND drafts parameterize and expose
CLAs so my concern isn't specific to what you have drafted.

The question being answered by the "Zero-Configuration CLA Discovery"
mechanism is really "where are the BP routers for my domain?" which I think is
different than the question you are asking which, I believe, is "given a host
or set of hosts in a DNS domain what, if any, CLAs are listening on the
host?". In fact, the zero-configuration section in the other draft might be 
better
titled "Zero-Configuration Router CLA Discovery" to distinguish its purpose.

Going back to what I think is your goal and question-to-be-answered, using a
SRV record on a specific host name rather than either SRV or DNS-SD on an
entire domain could get the information that you want in a way which is not
so ambiguous as the IPND code points.
Applying a SRV record to a host name rather than domain name is
slightly off-label use, but I think it's still technically allowed by
[RFC2782]. The point of this use is that the service applies to just the host,
and they are not interchangeable between hosts in the same domain.

For the example zone below, there are three BP nodes running on
host names "host-a" "host-b" and "host-c" and a standard query on
"host-b.example.com." will obtain both the host's available addresses as well
as the SRV records indicating what CLs are listening on which ports.
You could do something similar with a custom RRTYPE, but in this case the SRV
type will be directly usable with existing tooling and should not be confusing
to anyone observing the domain contents.

As Rick mentioned recently, it is better to not use any unregistered CL types
in your profiling document, but [RFC2782] itself allows for private use
service names, as it defines the service part as "The symbolic name of the
desired service, as defined in Assigned Numbers [STD 2] or locally." So
specific private networks could use whatever agreed upon service names are
needed as long as they don't collide with any IANA-registered names.


$ORIGIN example.com.
(
...
host-a  86400  IN  A  <IPv4>
_dtn-bundle._tcp.host-a  86400  IN  SRV  0  0  4556  host-a.example.com.
host-b  86400  IN  AAAA  <IPv6>
_dtn-bundle._tcp.host-b  86400  IN  SRV  0  0  4556  host-b.example.com.
_ltp-deepspace._udp.host-b  86400  IN  SRV  0  0  1113  host-b.example.com.
host-c  86400  IN  A  <IPv4>
host-c  86400  IN  AAAA  <IPv6>
_dtn-bundle._udp.host-c  86400  IN  SRV  0  0  4556  host-c.example.com.
)

[RFC2782] https://www.rfc-editor.org/rfc/rfc2782.html

> -----Original Message-----
> From: Rick Taylor <rick@tropicalstormsoftware.com>
> Sent: Friday, June 28, 2024 8:16 AM
> To: Scott Johnson <scott@spacelypackets.com>
> Cc: Erik Kline <ek.ietf@gmail.com>; dnsop <dnsop@ietf.org>;
> sburleig.sb@gmail.com; dtn@ietf.org
> Subject: [EXT] [dtn] Re: [DNSOP] RE: Re: IPN and CLA RRTYPEs to support
> Bundle
> Protocol RFC9171
>
> APL external email warning: Verify sender forwardingalgorithm@ietf.org
> before
> clicking links or attachments
>
> Hi Scott,
>
> I think we are talking at cross-purposes.
>
> I have no criticism of the valiant work you have done, and the circuitous
> route
> you have been forced to follow to get to this point.  The IETF needs more
> people
> with your 'can do' attitude, it will help all of us meet our endlessly
> slipping WG
> milestones.
>
> The DTN Working Group, of which I am a member, was asked their opinion by
> the DNSOPS folks and the DTN-WG AD to comment on your proposal, which I
> have done.  My comments were never intended to be perceived as an attack on
> you or your proposal.   The decision on registration of a RRTYPEs solely
> rests
> with the IANA and the Designed Experts of the registry.
>
> I fully support the use of DNS with Bundle Protocol, and have been a strong
> advocate for doing some kind of EID to CLA lookup, so I am extremely
> grateful
> you have put all this work in.
>
> With that in mind, the summary of my 8 comments on this proposal are:
>
> 1.  I (personally) think a CBOR encoding would be more future proof, but it
> is
> your decision on whether that is important to you.
>
> 2.  In order to resolve a DNS name to an ipn FQNN, using DNS lookup, I
> (personally) think that using a combination of SRV and TXT records will be
> easier
> to integrate into the current DNS ecosystem.  As Paul Vixie pointed out,
> that
> ecosystem involves more than just the nameservers.  But, again, it's your
> decision whether that is an issue for you.
>
> 3.  I find the CLA RRTYPE enumerated values of the form [CLA protocol]-[IP
> Version]-[BP version] confusing, but again, that might just be me.  TCPCL is
> the
> name of the convergence layer protocol used in the specifications, v4 is
> defined
> in RFC9174, v3 defined in RFC7242, both will operate over TCP/IPv4 and
> TCP/IPv6.   I would prefer to see a definition of TCP-v4-v6, TCP-v4-v7,
> TCP-v6-v7
> pointing to the correct combination of versions, or better yet something
> along
> the lines of just TCPCLv4, TCPCLv3.   The same applies to LTP and UDP.  If I
> was
> to implement this, I would expect a reference to a protocol specification
> that
> can reasonably describe what an CLA implementation resulting from a lookup
> is
> declared to support.
>
> 4.  Why is the IP version included?  Perhaps I am missing a hidden
> complexity of
> DNS here, but as a user, given a DNS name, can't I just lookup the RRTYPE
> for
> the CLA, and then use A or AAAA records to get either/both IPv4 and IPv6
> addresses via the same DNS name?  It seems like unnecessary doubling of
> values
> to me.
>
> 5.  Why is the BP version included? The relevant CLA specifications should
> (maybe all do) include applicability statements for the various Bundle
> Protocol
> versions.  If you need a DNS based lookup mechanism to determine the version
> of BP in use at a host, perhaps a third RRTYPE 'BPVER' would be preferable?
> In
> many cases the choices of BP version and CLA protocol to use are orthogonal.
>
> 6.  I assume STCP refers to the expired Simple TCP Convergence-Layer
> Protocol
> (https://datatracker.ietf.org/doc/draft-burleigh-dtn-stcp/)  This protocol
> was
> never adopted by the DTN WG, the draft expired in 2019, and the
> functionality
> superseded by TCPCLv4.  I would not recommend referencing this document or
> even the protocol.
>
> 7.  I find the inclusion if IPND inconsistent.  The only IETF reference to
> IPND that
> I could find is an IRTF draft that expired in 2016
> (https://datatracker.ietf.org/doc/draft-irtf-dtnrg-ipnd/) that describes a
> peer
> discovery mechanism, not a CLA.  Perhaps I have missed a reference (see
> point
> a), but I (personally) think that an RRTYPE called "CLA" should only contain
> CLAs.
>
> 8.  I understand that ION implements all the CLA RRTYPEs you have described
> above, which is great, but if this registration is specifically aimed at
> declaring
> implementation specific functionality, the document should state it.
> Alternatively perhaps restrict the registered values to those backed by
> publicly
> accessible current specifications, and add a "Private Use" range?
>
> Please feel free to ignore any or all of my comments if you disagree, they
> are
> meant to be constructive, not some kind of dictat.
>
> Cheers,
> Rick
>
> > -----Original Message-----
> > From: Scott Johnson [mailto:scott@spacelypackets.com]
> > Sent: 28 June 2024 10:12
> > To: Rick Taylor
> > Cc: Erik Kline; dnsop; sburleig.sb@gmail.com; dtn@ietf.org
> > Subject: Re: [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRTYPEs to
> > support Bundle Protocol RFC9171
> >
> > Hi Rick,
> >
> > As I have previously stated, I personally have lodged no objection to
> > using CBOR encoding of (node-nbr) in this case, and actually mentioned
> > the option myself.  Here is the situation as I see it:
> >
> > I have requested the creation in the IANA database of the IPN and CLA
> > RRTYPEs, by the means detailed in RFC6895, section 3.1.1; to whit,
> > completed (twice, one for each) the form found in Appendix A. of same.
> > My requests meet the criteria of part 2 of 3.1.1.
> >
> > I ran afound of section 3.1.2, point 1, as the Expert Reviewer
> > explained that I needed to designate wire and presentation formats for
> > the requested records, in Individual Informational internet-draft format.
> >
> > I produced that document, and, as suggested by Expert Reviewer, sent
> > it to DNSOP for review.  There, I received guidance on verbiage and
> > optimal choice of formats from DNS expert Mark Andrews.  I also
> > consulted Scott Burleigh, first named author of RFC9171, for any
> > particular BP related concerns.  With the help of, and achieving
> > concensus with these two learned individuals who possess significant
> > specialized knowledge of the two systems we are integrating in the
> > above described standardized process, we arrived at a viable document in
> several hours.
> >
> > Upon request of Transport AD, I forwarded to DTN.  Of the productive
> > responses received, Brian Sipos pointed out an interoperability
> > problem with the notation I wove from whole cloth (based on the
> > notation used in
> > IPND) to describe CLAs, and you requested information concerning
> > motivations of the document.  Time being of the essense, I
> > incorporated changes to address the point Brian made and added a
> > section to text describing my motivation.  I did so in short order, as
> > I did previously with the consultations on DNSOP.
> >
> > You raised technical challenges to the proposed 64-bit integer wire
> > encoding for IPN in this use case, citing RFC9171, and your own draft.
> > Section 4.2.5.1.2 clearly defines the rules for encoding of EIDs.
> > Only one component of EID is to be encoded in the RRTYPE, and hence,
> > not an EID.  Further, 64-bit integer is the preferred encoding of the
> > DNS experts, and Scott Burleigh has confirmed that this proposal
> > conforms to the encoding defined in your draft; an assertation which
> > has not been refuted.  It has also been confirmed that there is no
> > conflict between the registration of these RRTYPEs in the described
> > formats and the content of your draft.
> >
> > This particular encoding is not for use inside bundles or by BPAs;
> > indeed, it will only appear (please correct me if i am wrong, DNSOP
> > participants) internally inside nameservers and resolvers and on the wire
> between them.
> > Thus, these technical challenges seem to have been addressed.
> >
> > An alternate proposal was put forward in theory, fulfilled in part by
> > an expired draft by Brian Sipos, who has indicated that he does not
> > have time to work on that solution at present.  I believe him; I
> > imagine his workplace is exceedingly busy of late.  I know mine is.
> >
> > Having arrived at loose consensus with experts from both disciplines
> > involved, and lacking a good reason to further revise the draft which
> > is now before the Expert Reviewer for a decision as to the creation of
> > the RRTYPEs, I think the best course of action is to let the Expert
> > Reviewer do their job and approve or (hopefully not) deny the RRTYPE
> reservations.
> > The IANA registry will likely reference my draft if approved, and I
> > will likely be requesting at least one more RRTYPE to hold BPSEC data.
> >
> > If DTN WG wishes to take up this special purpose individual
> > informational draft instead of other pressing business it is chartered
> > for, it is free to do so.  It is in no way necessary to do so to
> > perfect my RRTYPE request procedure, and seems a waste of time to me.
> > If you want something for the WG to take up, I will be producing
> > another Informational draft soon which you will surely find
> > interesting concerning discrete DNS networks on different planetary
> > bodies interoperating by means of transiting IP request metadata
> > across the BP deep space network.  That, IMHO, is worthy of asking the
> attention of the group here assembled.
> >
> > Please understand; we are operating in an Adopt, Adapt, Author order
> > of preference when it comes to solving real world problems being faced
> > right now.  In this case, 'Adopt'ing new DNS RRTYPEs to distribute BP
> > information to IP speaking BP nodes fits the bill.  It "just works" in
> > a way that those who will use it will already understand, and is easy
> > to implement all the way around.  It may not be the best solution
> > possible, but it was the best one available.
> >
> > Thanks,
> > Scott
> >
> >
> >
> > On Thu, 27 Jun 2024, Rick Taylor wrote:
> >
> > > Hi Scott,
> > >
> > > <chair hat on>
> > >
> > > I absolutely sympathise with your need to "grab an RRTYPE and make
> > progress", but there is a process choice to be made here:
> > >
> > > * Do DNSOPS want the RRTYPE registrations to integrate with the
> > > wider work
> > of the DTN working group?  In which case discussion like this must
> > continue, and the document should be adopted by the WG.
> > > * Or is everyone happy to register the RRTYPEs as "ScottJ and
> > > colleagues
> > need some unique RRTYPEs for the solution they're working on - no
> > alignment with the wider work of the DTN WG implied"?  I would propose
> > calling the RRTYPE NODEID not IPN to make this clear, and not have the
> > reference specification be an IETF document.
> > >
> > > I'm genuinely not trying to scupper this work.  I'm actually happy
> > > with either
> > approach, I'm just trying to ensure moving fast doesn't accidently set
> > perceived standards that then consume WG cycles in the future to align
> > with current work.
> > >
> > > But before we consume too much more of all of our time, a decision
> > > needs to
> > be made on the approach, and I think Erik (DTN AD), the DNSOPS
> > Designated Experts/Chairs and Scott need to discuss their preferred
> > options.
> > >
> > > We have "Naming and addressing" as part of the DTN WG charter, so
> > > this
> > work could be adopted if the WG is willing, but that may not suit
> > Scott's timeline.
> > >
> > > Cheers,
> > > Rick
> > > _______________________________________________
> > > DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to
> > > dnsop-leave@ietf.org
>
> _______________________________________________
> dtn mailing list -- dtn@ietf.org
> To unsubscribe send an email to dtn-leave@ietf.org