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

[Magnus Westerlund <[e-mail]>]

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