Re: [dtn] Backwards compatibility between 'classic' ipn and ipn+

[Rick Taylor <[e-mail]>]

Hi Scott,

Can you please explain your assertion: "... existing DTNs become non-interoperable over time with anyone implementing your version of the scheme..." as I don't believe it to be true.  If it is true, then I certainly wouldn't support continued work on this topic.

Cheers,

Rick

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 20 November 2022 08:43
> To: Rick Taylor
> Cc: [e-mail]
> Subject: Re: [dtn] Backwards compatibility between 'classic' ipn and ipn+
> 
> Hi Everyone,
> 
> On Sat, 19 Nov 2022, Rick Taylor wrote:
> 
> >
> > Hi All,
> >
> >
> >
> > As I read RFC9171, it is very clear about the behaviour of a BPA that
> > receives a bundle with an EID it does not recognise:  Section 6.1.1 states
> > that a bundle status report of type 6 “No known route to destination from
> > here” should be sent to the ReportTo EID.  Conceivably a status report of
> > type 5 “Destination endpoint ID unavailable” could be used, but I have
> > always read that as “App is here, but not live” rather than “I dunno how to
> > forward that”.
> >
> >
> >
> > With the proposed updates to ipn, this behaviour remains unchanged, and
> > hence there would be no impact to an existing, interoperable DTN.
> >
> 
> 
> Your definition of "no impact" is puzzling as existing DTNs become
> non-interoperable over time with anyone implementing your version of the
> scheme.  I think this creates a splinternet whereby existing networks, if
> left unmodified, wind up being able to communicate only with null or
> original authority named nodes, but effectively remain disconnected from
> the new nodes with authority numbers.  This results in the eventual
> disconnection of existing resource holders.  The draft would marginalize
> the utility of my (and other's) naming resources, by relegating them to
> BPv6 use only, and would make communication with Nodes named with these
> resources fail in networks named with your new specification for naming
> resources.
> 
> Your draft appears to say that CBHE Node IDs were designed for BPv6 only,
> yet they have already been widely implemented with BPv7. I would tend to
> side with running code here as proof of intent.
> 
> I read the draft to outlaw the practice of deploying multiple Node Ids in
> a single node. This is a practice I have found both useful and effective
> in active deployment, and continue to use, as demonstrated at IETF 115.
> To require an individual application instance to be deployed per NodeID
> winds up wasting processor, memory, and power.  All of these should be
> conserved where possible, both in space and terrestrially.
> 
> The terrestrial Internet has benefited from an open philosophy.  Something
> along the lines of "if you are capable, and you are willing, you are
> welcome according to published and specified rules." is the accepted
> barrier of entry.  It would be quite a shame if we were to lose that
> inclusivity, just as we are progressing forward into the solar system.
> 
> > One of the major reasons for avoiding a new ‘ipn+’ scheme, is that would
> > require a new set of BPSec profiles to be implemented for asserting Node
> > identity for PKI, and that would be a major blocker to adoption.
> 
> Can anyone point me to a reference to what a "BPSec profile" is, in
> context of the relevant RFCs?  I have read, and searched digitally, lest I
> missed it, for the word "profile" in both of the most recent RFCs relating
> to BPSec. I fail to find a single instance.  Is this something that is
> implementation specific?
> 
> I do find reference to 'profile', and often (in the title and page
> headers, mostly) in a draft Ed put forward that expired in 2016:
> 
> https://datatracker.ietf.org/doc/html/draft-birrane-dtn-bpsec-suiteb-profile-
> 00
> 
> Ed, can you shed some light on this?  I understand the cryptography end.
> 
> This document has "None" for IANA considerations.  Similarly, there are no
> other documents referenced from this document which have relevant IANA
> considerations, or which, indeed, make any mention of naming schemes in
> relation to BPSec.  The only "profile" referenced in any of these
> documents is the "NSA Suite B Profile" specification for cryptographic
> algorithm selection.  I fail to see a conflict here.  What relationship
> does Bundle Protocol URI Scheme Types have with BPSec Security Context
> Identifiers, or the undocumented "BPSec profiles" that the former would
> have a dependency on the latter?
> 
> Enjoy,
> Scott
> 
> >
> >
> > Cheers,
> >
> >
> >
> > Rick
> >
> >
> >