[dtn-interest] Re: bundle security protocol

["Peter Lovell" <[e-mail]>]

Hi Wes,

your comments are very helpful and much appreciated.

I am just about to make extensive updates, since the current development
cycle is turning to test-mode, so the timing is exquisitely good. My
comments are included inline below, with the exception of those relating
to edit changes which I will just "deal with".

Thanks.....Peter


On Mon, Aug 13, 2007, Wesley Eddy <[e-mail]> wrote:

>Here are some comments on draft-irtf-dtnrg-bundle-security-03, after
>reading it carefully last week.  I haven't been closely following
>discussion on this lately, so please forgive me if some of these
>comments are already known or addressed in a planned update.  Also, I'm
>sorry for the grossly long email, perhaps some of these should be
>followed up in distinct threads:
>
>0) Overall, it seems like there are still a couple of interesting open
>   issues for research.  The current BSP looks like an evolutionary step
>   forward from "no security" to allowing some classes of deployment of
>   bundling agents to provide reasonable security services.  But would I be
>   wrong to say (or would anyone echo the sentiment) that the BSP isn't yet
>   capable of meeting all the goals of the DTN architecture?

I agree - we handle some things but not all. And some of the ones we do
have need revision in light of various changes.


>   In addition to key management, what key goals can we identify for
>   needed advances?  I think comments 14 and 15 below may be a start, but I
>   believe there may be others.

One which cropped up recently is the differentiation between processing
for "payload stuff" and processing for "other stuff". Right now
ciphersuites are generic and I believe we need to change that. The
discussion is too long for here but the current approach needs work.



>6) Ciphersuite ID - why is this 16 bits?  Should it be an SDNV, even just
>   for consistency's sake?  It wasn't clear to me why this was decided to
>   be fixed-length.  It seemed to me like it should really be 2 SDNVs
>   instead of a single 16-bit field (one for format flags indicating
>   what other fields are present, and one for identifying the algorithms).
>   This would currently yield the same on-wire length since there are only
>   5 flags and a handful of algorithms, so it seems like a clear improvement
>   unless I'm missing some point.

I believe this is just historic. It could be SDNVs without major impact.

>10) Canonicalization - This isn't a very crunchy or actionable comment; I'm
>    sorry.  Canonicalization seems like it could be the major impact on
>    performance of the BSP, and it's certainly an ugly thing to have to do,
>    although I understand and accept that it's needed.  Are there
>    performance profiling numbers available on this?

Having just worked through the code for PS2, I agree it can be a major
impact. My head is still hurting from all the gyrations needed. I have
done no profiling [yet] but I don't expect it to be pretty.


>14) Another, un-actionable comment: "This specification does not currently
>    define any ciphersuite which can handle this reactive fragmentation case
>    well."  Reactive fragmentation has been a thorn in the side of a few
>    mechanisms in this RG.  I wonder if it is really a feasible part of
>    the architecture in general, or if we have to take an IPv6-like path
>    forwards and only allow proactive fragmentation, or convergence-layer
>    "suspend/resume" functions for interupted bundle exchanges (rather than
>    reactive fragmentation).  In anyone else's minds, would this simplify
>    things significantly or at least alleviate some floundering on the issue
>    that parts of the instantiated DTN architecture don't and forseably
>    won't nicely support reactive framentation?

There are some scenarios where reactive fragmentation can be useful, but
it's a small subset of the overall dtn capability. For end-to-end
security, fragmentation is not too much problem since all the pieces
will [should] arrive and be available for assembly. The big problems
come at intermediate points where only partial data is available. 


>15) "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."

heh
>    This implication had bothered me from the moment

Me too, which is exactly why I added this statement to the spec last
time through. There are huge implications and they seemed to be
receiving scant attention so I wanted to be sure that the implication
was at least on record.

>    This implication had bothered me from the moment I thought about the
>    format of the abstract security block in 2.1, and is (I think) very
>    bad.  If a security-destination is added that differs from the
>    original bundle's destination EID, should the original be pushed into
>    the security block, and popped later after processing by the security-
>    destination?  I'm sure there could be huge problems with this too, but
>    it seems to me like presently, without a security-source having some
>    routing path knowledge, adding security-destinations that aren't the
>    final destination is tricky at best.  You might often be forced to
>    use a multicast EID as the security destination if you don't know
>    exactly where a bundle will enter/exit your enclaves, which seems like it
>    could be unpallatable for keying (but I guess that would be easier to
>    answer after there's a crispy proposal for key management).

I do not have a good answer for this, or even any proper answer at all.
The closest I've come is to have a "routing info" block of some sort as
a hint for forwarding nodes that they need to direct this bundle to the
specified node. Your suggestion to push/pop the destination into
security may be better. After all, if the content is encrypted then it
needs to get to security-dest. Flawless delivery to the destination but
bypassing the decrypt node is kinda useless :)