Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4

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

Following up on this thread: I've posted an Internet Draft for a somewhat revised bundle-in-bundle encapsulation spec that does the kinds of things I was hoping to accomplish with bundle encapsulation and is, I think, a little simpler than the original design.  It's at http://datatracker.ietf.org/doc/draft-irtf-burleigh-bibe/.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Burleigh, Scott C (313B)
Sent: Wednesday, January 23, 2013 11:05 AM
To: [e-mail]
Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4

You're right, Angela, I definitely wouldn't want bundles to have to be encapsulated every time any security block was added.  The idea here would be that you only encapsulate bundle Q whose source is A and whose destination is Z if you know -- at the time you are forwarding Q -- that in order for Q to reach its destination safely it has got to traverse an additionally secured path segment from node X to node Y.  In this case you'd create a new bundle R whose source is X, whose destination is Y, and whose payload is Q, to which you would attach the required additional security blocks.

That is, you'd encapsulate under exactly those conditions under which, in 6257 as written, you would annotate your additional BSP extension blocks with security source and security destination other than the original source and final destination.  The reason to do this would be to delegate to Routing, in a straightforward and transparent manner, the job of ensuring that the bundle is forwarded to the security destination.

If a node just wants to add a signature to a bundle, the question is whether the node that will validate that signature (and therefore must know the corresponding key) is the final destination or some interim destination that the bundle MUST be routed through.  If the latter, then yes, you'd have to encapsulate, because you're constraining the routing system.  If the former -- and if the validating destination node doesn't care which node attached the signature -- then no.

You're right that encapsulation would eliminate non-destination nodes' ability to peer into the original bundle's payload.  Is that really a desirable feature?  I'm a little skeptical that we should rely on any node other than the final destination having access to the payload; certainly if the payload were encrypted this ought to be moot.  Maybe there's still some desire to be able to support deep packet/bundle inspection in firewall-like structures, but I'd think that anything as intrusive as that wouldn't be deterred by a bit of encapsulation.

If a node wanted to sign and then encrypt a bundle, there would need to be additional encapsulation if the node that must decrypt the bundle and/or the node that must validate the signature is other than the destination node.  Again, you'd have to encapsulate in order to cause the bundle to be routed in the manner in which you require it to be routed.

The same general principle would apply to extension security blocks.  If the bundle has to be routed to a specific node in order for extension blocks to be decrypted or validated -- and that node is different from the destination node and from node to which it must be routed for the purpose of decrypting/validating the payload -- then you'd have to encapsulate in order to cause the bundle to be routed in the manner in which you require it to be routed.

I think you could still encrypt different extension blocks with different keys without encapsulation, so long as the bundle's destination knew all of the keys.  Maybe you'd still want correlators to indicate which keys apply to which blocks, but I would think that would be managed by policy rather than by instructions carried in the bundle.  If not, though, then you're right, we wouldn't be able to get rid of correlators.

One thing that this concept does is force the forwarding node to actually know what it's doing.  It's no longer sufficient just to attach several security blocks and let the network try to figure out what you meant.  You have to have an actual plan for effecting all of the processing that you are going to require, because that plan will drive the order of encapsulation and security block attachment.  I see that as an advantage rather than a drawback, though.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Angela Hennessy
Sent: Wednesday, January 23, 2013 10:03 AM
To: [e-mail]
Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4

Hi Scott,

I like how this approach simplifies the routing and gets rid of the security src/dest and EID refs. I was a little confused though about how this would work with some of the combinations of security blocks:

If a node just wants to add a signature to a bundle, would this require the bundle to be encapsulated? One of the advantages of BSP is that non security-aware nodes can still access the payload by just ignoring the PIB block. Wouldn't we lose that feature if the bundle were encapsulated?

If a node wants to sign and then encrypt the bundle, does this require the bundle to be encapsulated twice?

How would we handle signing/encrypting extension blocks? Would this require a third encapsulation? Wouldn't we still need correlators in case multiple extension blocks are encrypted with the same key, or would we not allow different extension blocks to be encrypted with different keys?