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

[[e-mail]]

Hi Rick,

On Sun, 20 Nov 2022, Rick Taylor wrote:

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

Sure, but you have to tell me what a "BPsec profile" is first :)

I think Scott B. and Jorge have made this point pretty well already, but I 
will offer a hypothetical example:

Lets imagine a hypothetical sensornet for collection of environmental data 
that deploys BPv7, using CBHE Node Ids in the ipn naming scheme to name 
its constituent hosts.  The sensor nodes are remote, perhaps even mobile, 
as in the case of a network which tracks the territorial boundaries of a 
certain species of porpoise, for example.  This network segment can 
reasonably fall within the intersection set of the Vinn diagram with sets 
including a) not reasonably field upgradable, b) uses BPv7, and c) uses 
CBHE Node IDs.

These sensors log their GPS data, all day long, and when they are in range 
of one of the base station network devices, they dump their data in 
bundles to it, per spec.  These base station nodes, in turn, wait for a 
satellite (perhaps even a cubesat) to pass over, at which point they dump 
the data to the satellite.  The base stations are necessarily remote as 
well, although perhaps they have remotely upgradable firmware, if you are 
comfortable with flashing firmware over an intermittent circuit; I can 
speak from experience that this practice is harrowing to carry out and 
fraught with peril.  The satellite component can also pretty easily be 
classified as "not field servicable," despite the fact that we could, in 
fact, match orbit with it and monkey around, if necessary.  The satellite 
is probably sophisticated enough that there is a reliable method to 
upgrade the relevant firmware, because the cost of deploying a satellite 
is somewhat more than deploying a remote sensornet base station.

So, sensornet (not upgradable), base stations (maybe upgradable), 
satellite (probably upgradable).  The satellite, once it has collected the 
data, sends it along through the IPN network, until it hits a 
groundstation, where the bundles are now carried over IP, until they reach 
the researchers operating the sensornet, who are very happy when they 
reliably get their data.

What happens when the IPN network that the data passes through implements 
a non-identical naming scheme to the one implemented on the sensor nodes? 
Those nodes recognize the additional authority field as corrupted data, as 
Scott B indicated. The bundles don't make it through.

What happens when those researchers don't have a core competency in delay 
tolerant networks(because they are studying porpoise), and suddenly, 
their data stops showing up?  They are no longer happy.

This example use case shows that it is non-trivial, and sometimes 
impossible, to update software/firmware on devices in the field.
Imagine chasing down all those porpoise on a jet ski, laptop, screwdriver, 
and USB cable in hand, ready to upgrade those sensor nodes.

ScottJ

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