[dtn-interest] bundle security protocol

[Wesley Eddy <[e-mail]>]

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?

   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.

   I think it would be good to document these quickly in a bulleted list
   at the end of this draft.  As an RG product, it would clearly identify
   what further research would be useful and productive.  This could be
   especially useful since these would probably be the barriers between
   an Experimental and standards track protocol farther down the line.

1) I know this is just mincing words, and I don't consider it an
   important issue, but a point of small reader confusion:

   The BSP - Bundle Security Protocol - consists of 3 different types of
   blocks, rules and policies for processing bundles and blocks, and
   algorithms for use within processing, but there doesn't really seem to
   be anything tangible that could be named "BSP".  It's more of a
   "framework" than a "protocol", right?

   I also realize that their are common elements like the abstract security
   block format and canonicalization rules, but these still strike me
   more as framework than protocol.

2) Figure 1 - "Net1", "Trans1", "Net3", and "Trans3" become "N1", "T1",
   "N3", and "T3", in the 2nd and 3rd nodes.  These should be consistently
   labelled.

3) Early on, I would appreciate more motivating discussion on lower layer
   and upper layer security mechanisms, and how they can (or can't)
   supplement/complement/replace each of the BAB, PSB, and CB services.
   I know this is already aimed at in the "Security Overview and
   Motivations" document, but I feel it would be helpful to summarize it
   in 1-2 paragraphs in the introduction here.

4) Labelling/naming of fields between the text of 2.1 and Figure 2 is not
   consistent.

5) In Section 2.1: "indicated by by" -> "indicated by"

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.

7) In 2.3 on the PSB - "the security information can be checked at any
   hop on the way to the destination that has access to the required keying
   information." Yes, but, SHOULD it?  Under what circumstances?  What
   should it do if the check fails?  I know this is discussed further later
   on within the document (although still a bit mushily), so maybe just
   adding text like "as discussed later within this document" would be a
   good idea.

8) Section 3.1 - In the paragraph "All nodes serve as ...", there is an
   either confusing or outright wrong mashup of terminology that muddles
   whether policies apply to the interaction with apps that request
   bundling services through a registration to a bundle agent, or to the
   interaction between bundle agents via bundle forwarding, or both.
   Rewriting this to clarify the intent is needed.  Perhaps splitting it
   into two paragraphs to address the two different policy sets would be
   advisable.

9) Section 6 - "PEP" is redundantly redefined (first instance was in 3.1).
   
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?

11) "node SHALL discard" is better to my ear as an implementer if phrased
    as "node MUST discard", and equivalent by BCP 14, but this is just a
    small and unimportant suggestion.

12) The presence of the "At-Most-Once-Delivery" option affects the
    registration between an application and a bundle agent, since that's
    where it is specified, but I don't believe it's related to the BSP.
    Is it?

13) As a larger point to consider, if we can use registration signalling
    to turn on the At-Most-Once-Delivery behavior, should we also use it
    to let applications request CB or PSB services?  I do believe so.

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?

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

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

If you've survived reading to this point, thanks for your attention!

-- 
Wesley M. Eddy
Verizon Federal Network Systems