Re: [dtn] DTN addressing, routing, and ownership

["Burleigh, Scott C (US 312B)" <[e-mail]>]

Hi, Magnus.  Again, there really are no addresses; the source information provided in a bundle is the source node's ID, not its address.

That said, the question of how to determine the authenticity of the source node ID asserted for a bundle is certainly important.  The mechanism that we've been developing in the ION implementation would be:

1)  Each node generates its own public/private key pair, never discloses its private key to anybody, and publishes its public key to everybody.

2)  Whenever a node transmits a bundle, it include a Block Integrity Block covering the primary block -- including the source node ID -- that is signed in the node's private key.

3)  When a node receives a bundle, it uses the source node's public key to verify the BIB for the primary block.

There is of course more to it than these three lines, much of which we've discussed in a couple of I-Ds, and I have no doubt that there are problems that we have not yet addressed.  But at this point I don't of anything that makes the problem insoluble.

As you say, the anonymization across public/hazardous networks that can be provided by bundle-in-bundle encapsulation may address the use cases for which it has been asserted that bundle anonymity is required.  This seems well worth discussing. 

Scott

-----Original Message-----
From: Magnus Westerlund <[e-mail]> 
Sent: Tuesday, July 21, 2020 4:06 AM
To: [e-mail]; [e-mail]; Burleigh, Scott C (US 312B) <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [dtn] DTN addressing, routing, and ownership

Hi,

After having read this discussion I would like to ask some questions here.

On Mon, 2020-07-13 at 16:45 +0000, Rick Taylor wrote:
> Scott,
>  
> Top-posting (again). Sorry.
>  
> As usual I conflated 2 points into one email.  Breaking them apart:
>  
> 1.       Source-Id Anonymity – this seems bad.  Can we make a valid Source
> Node_Id MANDATORY?  (That allows intermediates to make up their own 
> minds about what validity means, but at least it’s present)

So the big quesiton is does the Source-ID matter here. Can the originating node lie and include any address here, and are there any part of the routing system that can determine that this is a lie. With the late bidning concept for routing necessary to make the store and forward aspects of DTN work, I wonder what possibilities that do exist here? 

We can note that even in IP source address validation is only possible at certain points in the routing system and that are edge access networks where a router knows that a certain set of source address are possible as source address for traffic going to the rest of the Internet. So does any of you DTN experts have a view of how one could verify the source address? 

One could also use security mechanisms to cryptographically attest a source address so that nodes that like to verify an address could do it. However how ones does this in scalable way both from processing as well as being able to determine the trust anchors for verifying the attestation. At least DTN has a chance to scale its bundle sizes to where the number of bundles per second needing processing is kept reasonable even as bandwidth increases. 

For this later mechanism, is there a point of requiring the source adddress in base header, or could that just as well go into the extension block with a cryptographical attestation?
 

> 2.       The Source-Id in the Primary Block is certainly sufficient for
> monitoring, and will help a lot.  My (badly made) point was that a “Reply-To”
> in the Primary Block would add extra useful information, so that 
> monitoring tools could see the conversation flow between to EIDs, 
> rather than just the flow of bundles in one direction from a node to 
> an endpoint, without having to deep-dive into the payload each time.  
> The difference is purely the ease of access to the meta-data.  It’s 
> the difference between seeing IP packets flowing from source to 
> destination, and being able to watch a TCP session flowing between applications.

To my understanding with the help of bundle-in-bundle encapsulation there are at least some mechanisms to build anonymizers. But, maybe there need to be some thought here about what privacy aspects are provided here and what is needed for the primary purpose of getting the bundle to the destination and the secondary concerns of adminstrating and monitoring the networks function. I think a lot have to do with what DTN network scenario you have and what your primary risks are. 


Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------