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

[[e-mail]]

I think this push/pop idea makes the most sense of anything we've talked
about. It seems like it would require some modification to the spec,
however, and maybe a flag to set when the bundle-dest is being stored
somewhere.


Thanks,
Angela

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