Re: [dtn-security] Implementing Security Destinations in DTN2

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

Actually ION exercises something like this push/pop mechanism, internally, in route computation, and I suspect other implementations do it as well: in the course of computing the route to the final destination, the forwarder may select an interim endpoint to forward the bundle to and may then re-enter route computation in order to figure out how to route the bundle to that interim endpoint.  So long as all the routers along the path follow the same strategy, there's no need to record the interim endpoint in the bundle; it's an internal procedure.

None of the ION forwarders currently pay attention to security destinations when computing routes, so security destinations are never chosen as interim endpoints, but that modification seems plausible.  You'd want to be sure that the block citing a given security destination was always removed as soon as the bundle arrives at that destination, though, and we would want some sort of extension block ordering convention (or whatever) for nesting security destinations in a standardized way.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Peter Lovell
Sent: Tuesday, September 04, 2012 10:25 AM
To: [e-mail]; [e-mail]
Subject: Re: [dtn-security] Implementing Security Destinations in DTN2

>We're working on adding support for defining security 
>source/destinations in DTN2 (which could be different than the bundle src/dest).
>
>This raised the issue of whether or not we should route the bundle to 
>the security destination (if defined), rather than the bundle 
>destination. If we don't route the bundle through the security dest, 
>then it may be discarded at the bundle dest if it did not pass through 
>the security dest in transit.
>
>There are also some practical issues that are raised. There can be a 
>security destination for PIB/PCB, and a (possibly different) security 
>dest for ESB, and we'd have to decide which one to choose.
>
>Also, the routers in DTN2 access the bundle destination themselves, i.e.
>bundle->dest(). They would each have to be corrected to use some other
>value.
>


Hi Angela,

a problem indeed!  We did discuss this during development of BSP ...

>Specification of a security-destination other than the bundle- 
>destination creates a routing requirement that the bundle somehow be 
>directed to the security-destination node on its way to the final 
>destination.  This requirement is presently private to the ciphersuite, 
>since routing nodes are not required to implement security processing.

At one point I suggested that addition of PCB should adjust the bundle-dest to be the new security-dest, saving the previous bundle-dest for later restoration. This would certainly cause the bundle to be properly processed with regard to decryption. Although there might be other side-effects, no-one proposed any, however the plan was not adopted. The "nesting" characteristic of PCBs would mean that nodes were visited in correct order in the case of super-encryption.

I am not sure how this might interact with ESBs. I think that adopting the same approach (use security-dest as bundle-dest, save bundle-dest for later restoration) should work and produce a correct result. However I will admit that I haven't pondered the ESB/PCB interaction very much. I think it should "just work".

There might be other ways to adjust routing to ensure that the bundle visits the appropriate nodes. But those would require extensive changes to both BP and routing schemes -- neither of which seem likely. So the push/pop idea for bundle-dest seems to be the only realistic solution. Of course, there needs to be an EID-ref maintained in an EID-list somewhere so that dictionary compression/adjustment doesn't break things. That would be something like the plan for the list in the ESB.

Cheers.....Peter






_______________________________________________
dtn-security mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-security