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

[Peter Lovell <[e-mail]>]

Hi Scott and Angela,

I said some messages ago that I hadn't thought about this too much but expected it to "just work".

I've thought about it some more, and the more I do, the less attractive it is. The scenario I had in mind with my earlier comment is a suitable one but unfortunately it's about the only one.

Let me first set some context to help my description. Assume we have a DTN

  S  --  GA  -- I1  --  I2  --  GB  --  D
                    \        /          |
                     \- I3  --  GC  --  E


S and D are source and destination on controlled-access networks
E is a node on another controlled-access network, with a slow link to D
GA, GB and GC are gateway devices between those networks and an open network
I1, I2 and I3 are intermediate nodes in the open network

Assume also that there may be alternate, but similar, paths between S and D.

If GA's security rules require traffic to D to be protected across the open network, it will encrypt it using PCB with GB as security-dest. It will use GB as security-dest, rather than D, because it doesn't want the keys to be distributed any more widely than necessary. I realize that cool key-distribution schemes can ameliorate this problem but I'm imagining this to be a network subject to delays and/or bandwidth constraints, so GA and GB have been established with paired keys. GA also has a GA-GC keypair for sending bundles to E.

In this scenario, the bundle from S, gatewayed though GA must be sent via GB so it can be decrypted there and sent on its way. If node I1 finds that node I2 is slow/down/whatever, it might decide to route the bundle through I3. I3 does not know the details of the controlled-access networks but knows that GC can get it to D. So I3 sends it that way and the bundle arrives at D, still encrypted.

A good solution for this problem is for GA to specify GB as the [temporary] bundle-dest so that I1/I2/I3 will be forced to route it there. This obviously requires that GA save the real bundle-dest somewhere TBD so that GB can restore it. This will work even in the case of super-encryption, as the PCB nesting rules force the push/pop operations to be match correctly. So the idea works well for this case.

Thinking now about PIB, it seems to me that the public key needed to verify the bundle will not be very secret. In fact, I have yet to be convinced of any utility at all for a specific security-dest in the case of PIB. Any intermediate node should be able to verify the integrity of a bundle.

So now let's think about ESBs. For the reason mentioned above, an integrity check on an extension block seems to be a non-issue -- any node should be able to verify integrity. Which leaves the matter of confidentiality for an extension block. Now, I see the issue of confidentiality for an extension block as quite separate from that for the payload. Over the years we've discussed various scenarios where routing and search actions might be performed on metadata, so that some metadata would be available through keys that were known more widely than those for the payload. For example, metadata might indicate that the payload was a map covering certain coordinates. Another metadata items might specify the times for which the map was valid. And the map payload would indicate the various unit dispositions at that time. The "coordinates" key might have broad distribution, the "time" key be more restricted and the payload key the most closely-held.

But now I wonder about just what meaning we should attach to "security-dest" for an encryption ESB. In the scenario above, I would not expect that the ESB would ever be decrypted and the clear-text content be stored back in the bundle. Instead, it would be decrypted for immediate use but remain unchanged in the bundle.

I'm sure there are other planned uses for extension blocks and it would be a help if we can craft a few sample use cases so we can think more fruitfully about this problem. This would really help, because I'm imagining horror scenarios where various nodes add an ESB and push the bundle-dest and the bundle routing suddenly goes very, very bad. PCB is OK because there's only one payload, and onion-layering enforces nesting. That's not the case for ESBs so things could go bad.

To go back to Scott's comment - it does make sense if we can have some controls and sequencing on it. The push/pop scheme must have a single list and clearly-defined rules, and that means that PCB can't be allowed to do it on its own (unless it's forbidden to all others - not a good proposal).

Doing anything of this kind will certainly require changes to 5050. I have heard occasional rumblings that there might be a revision to it so let's think about what we might want/need, and be ready with well-considered proposals.

Regards.....Peter



On Thu, Sep 12, 2013, [e-mail] <[e-mail]> wrote:

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