Re: [dtn-interest] Re: bundle security protocol

[Stephen Farrell <[e-mail]>]

Just sticking my oar in before I go on hols...

Peter Lovell wrote:
> Hi Wes,
> 
> your comments are very helpful and much appreciated.

Agreed. Good to get more review of this stuff.

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

True. Text about that should go in the sec overview though, otherwise
we'll never get this one done. I'd have no problem renaming this I-D
to make it clear that this one is the analog of ESP and not IKE etc.

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

Authorisation.

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

I'd rather not change, just about. There's no reason I can imagine
to want that many ciphersuites - each additional one is a potential
non-interop opportunity, so there's a specific reason in this case to
not want too much extensibillity. (Some ECC fans once turned up at
a TLS meeting wanting to define 96 new ciphersuites, each of which
was some other (non)encumbered variant ECC suite - a bad idea.)

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

I think that if you need a security destination != destination then
you should arrange routing so that that works. VPNs do that kind of
thing all the time, so I'd be ok with not trying to provide a
solution for now,

S.