[dtn-security] Comments on DTN Security Overview]

[Howard Weiss <[e-mail]>]

Susan,

I've gone through your DTN security overview.

First, thanks for writing all of this down.  This was good - we've 
talked about a lot of pieces of this in various fragments of other stuff 
and its nice that someone finally had the time and funding to sit down 
and seriously write it all down.

At first I started reading it electronically but I hate to say it, I 
felt handicapped that it was a text file and that I didn't have the 
ability to insert comments and changes as in Word (wow did I just say I 
liked something that Microsoft produced??).  So I ended up printing it 
out and writing stuff in the margins which I was going to type up.  But 
then I just got lazy (the mark of a good engineer - so one of my 
undergrad EE professors always use to tell us) and I just scanned in the 
whole lot and made it into a PDF.  It looks like you should be able to 
read my marginal comments - if you can read my handwriting that is. 

I want to say up front that I have not read Stephen's comments - I 
wanted to go through this first without being "tainted" by another 
reviewer.  And I still have not gone back to read his comments so I have 
no idea how much overlap there is.

Some general comments:

1. While I think this was a good thing to do, I have some serious 
problems with what is being said.  Sometimes its not clear who is doing 
what with whom.  The whole notion of source, destination, sender, 
receiver needs to be revisited to make things clearer.  Plus there are 
times when you don't use the term destination and use other terms in its 
place.  Its still confusing without a road-map (which I had to draw to 
keep myself understanding).

2. While you mention that public key or symmetric key crypto can be 
used, you state that the symmetric keys are between bundle router 
pairs.  Youch - this implies that every two communicating entities would 
have to have a symmetric pair.  Talk about an explosion of keying.  Way 
back when we started talking about this we were thinking more along the 
lines of a net/group symmetric key to keep things simple. 

3. Speaking of more confusion, there are a number of "bundle" terms 
used.  For example, "bundle agent," "bundle router," "bundle security 
policy router."  Personally, I never envisioned a gaggle of devices - 
the bundle agent was the same thing as the bundle router - maybe w/o a 
convergence layer.   Do you really see a bunch of different flavor 
devices being developed?

4. You've left out the use of keyed hashes - a la HMAC - that might 
suffice for the hop-by-hop authentication.

5. Its also confusing who does payload security.  In one place it sounds 
like its the application.  But in another place it sounds like its the 
bundle agent.  It looks like you've adopted a model of the bundle agent 
looking like a firewall/VPN router - that is, a standalone device acting 
like a front-end.  However, I always envisioned a bundle "thing" more 
like IPSec which can be run in either tunnel or transport mode.  It can 
be a separate box or it can be part of the end system depending on the 
environment.

6. The whole issue of "optional" security is coming back to haunt me.  
First, do we have a definition of "optional?"  Is it like IPv4 where its 
optional to implement and use or like IPv6 where its mandatory to 
implement but optional to use?  Then there is the discussion about 
mixing secure DTN elements with non-secure DTN elements.  On a global 
scale, I don't know how that will work.  It could work on private DTNs 
but not on an Internet-like DTN overlay where bundle agents sit on 
whatever network where-ever.

Take a look at the comments and we can talk or meet or meet.

I will also endeavor to look through Stephen's comments.

Regards,

Howie

-- 
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)