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

[[e-mail]]

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
> 
> 
>