Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.

Scott Burleigh <> Tue, 31 May 2005 17:52 UTC

Received: from ( []) by (8.11.6/8.11.6) with ESMTP id j4VHqRV30028 for <>; Tue, 31 May 2005 10:52:27 -0700
Received: from ( []) by (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4VHqCVl002522; Tue, 31 May 2005 10:52:12 -0700
Received: from [] ( []) by (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4VHqBMC001528; Tue, 31 May 2005 10:52:12 -0700
Message-ID: <>
Date: Tue, 31 May 2005 10:52:10 -0700
From: Scott Burleigh <>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: "'Howard Weiss'" <>, "'Stephen Farrell'" <>
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Source-IP: []
X-AUTH: Internal IP
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: DTN Security Discussion <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>

Susan F. Symington wrote:

> All,
> Attached is our first draft of the DTN Bundle Security Protocol 
> Specification. Please read it and provide comments. Ideally we would 
> like to have an 01 draft available by mid July, in time to be 
> considered at the next IETF meeting, so we would appreciate receiving 
> your comments in time to be considered for the next draft.

Hi. I've got a few comments on the substance of the spec, but not many; 
you guys know plenty more about this stuff than I do. Most of my 
comments are on its form, and many of them respond to the points you 
raise below.

> This Bundle Security Protocol will require the following changes to 
> the base Bundle Protocol Specification:
> - need a Statment in the Bundle Protocol that security is RECOMMENDED 
> to implement and OPTIONAL to use


> –- need a new Confidentiality header type

I don't think this should be in the Bundle Protocol (BP) spec, though. 
All three security headers are extension headers; they should be 
documented in the Security spec, just as any other extension header 
should be documented in the spec that defines its content and use.

> - need to remove text about authenticating the BAH from the bundle 
> processing steps

Yes. In general, I think the clearest way to link these two documents in 
a cleanly decoupled fashion is this:

1. Number most of the paragraphs in the BP spec individually, so that 
other documents can easily refer to them.
2. Include in the BP spec, somewhere at the start of the procedure 
specifications, a note to the effect that "the procedures mandated by 
this specification are neither exhaustive nor exclusive; supplementary 
DTN protocol specifications (including, but not restricted to, the 
Bundle Security Protocol) may require that additional measures be taken 
at specified junctures in these procedures; such additional measures 
shall not override or supersede the mandated BP procedures, except that 
they may in some cases make these procedures moot by requiring, for 
example, that implementations conforming to the supplementary protocol 
terminate the processing of a given incoming or outgoing bundle due to a 
fault condition recognized by that protocol."
3. Remove all other security-specific language from the BP spec.
4. Modify the Security spec to say things like "The following procedure 
MUST be performed immediately before the start of the BP procedure 
described in w.x.y.z: blah blah blah."

> - need to remove BAH and PSH header format descriptions


> - need an at-most-once delivery parameter of the Register.request 
> primitive

Here I think what's needed is a notion of extension parameters, along 
the same lines as the extension headers and extension procedures. That 
is, at the start of the service interface section of the BP spec we can 
say "the list of parameters specified for each BP service primitive is 
not to be understood as exhaustive or exclusive; supplementary DTN 
protocol specifications (including, but not restricted to, the Bundle 
Security Protocol) may require that implementations conforming to these 
protocols provide additional parameters with specified primitives." Then 
the Bundle Security Protocol can say which additional parameters are 
needed with which primitives, and what they mean, without constantly 
having to go back and tweak the BP spec whenever anything changes.

> - need to remove the primary bundle header security flags field


> - need to add a sender field to the primary bundle header

I don't think so. I went back through the document and didn't find any 
mention of the "sender" being used for any purpose other than security. 
I think it belongs in the BAH.

> - in description of forwarding steps, need to put the endpoint ID of 
> the sending bundle protocol agent into
> the dictionary (if it's not already there) and place its offset in the 
> sender field before forwarding the bundle

Let's say this in the Bundle Security Protocol spec instead.

> - need modifications to the send.Request and Data.Indication Delivery 
> Options Security parameters to
> be able to pass appropriate parameter (e.g., ciphersuite parameters)

Again, I think this is covered by the "extension parameters" idea; let's 
document these modification in the Bundle Security Protocol spec.

Other comments:

1. The terminology is of course completely messed up by our decisions of 
two weeks ago. I will try to have a revised draft of the BP spec out by 
the end of next week, which may (or may not) help clarify everything.

2. In section 2.2: is it your intent that the CH remains in the bundle 
even after decryption by the CH security destination, so that it can 
appear in the Data.indication at a bundle destination that isn't the 
decryptor? If so, what's the rationale for that? Likewise, does the PSH 
remain in the bundle even after verification by a PSH security 
destination that isn't the bundle destination?

3. A note on 2.3: now that everything that sends or receives a bundle -- 
including routers -- is a node, this capability protects routers as well 
as end systems from replay.

4. In section 3.1: if you use really big keys, does this cause the 
security result (the result of applying a key in a calculation) to be 
really big as well? Too big to fit into 16 bytes? Do we need SDNVs to be 
coded for 1-2-4-8-16-32-64-128 for this purpose, or will the 
1-2-3-4-5-6-8-16 coding Mike proposed be sufficient?

5. In section 3.4, a minor typo: in the first paragraph you say PSH when 
you mean CH.

6. Section 4.2: I don't think we really need to have a canonical form 
for bundles; instead, the Bundle Protocol Specification needs to define 
the canonical sequence in which bundle data elements are considered in 
the calculation of signatures, MACs, etc. The former is the physical 
form -- the on-the-wire format -- of the bundle, which doesn't matter; 
the latter is the *logical* form -- the Security Protocol's view -- of 
the bundle, which can always be readily computed from the former. You're 
already implicitly recognizing this by talking about headers that are 
"(logically) removed" from the bundle prior to calculation and endpoint 
ID strings that must be "substituted for their corresponding fields in 
the concatenated bundle header." I think it would greatly simplify the 
spec to simply say something like "the BSP view of a bundle shall 
comprise the logical concatenation of the following data elements" and 
then talk about performing calculations on the BSP view of the bundle. 
(You do something like this in the third paragraph of 4.3, third 
sentence. I think it's the right approach.)

7. Did we ever finally decide whether or not the Override Report-to 
Header was in the Bundle Protocol spec? I've lost track; I'll do some 
research in my email archive.

8. In section 4.8: what do we do if one node that's registered at some 
endpoint ID says "at most once" and another one says it wants all 
copies? We can't simply "discard" the replay.

9. In section 4.12: it's starting to look as if we could end up with a 
large and maybe open-ended number of possible bundle status values, and 
I don't know of many cases where these values aren't mutually exclusive. 
I'm thinking it's time to switch from having a Flags byte here to using 
a status code number; might as well make it a 16-bit number to allow for 
lots of extensions. And, again, the BP spec is going to have to say that 
the values it defines for this code are not the exclusive and exhaustive 

10. In section 4.13: I think the "extension parameters" idea needs to be 
applied to the "services required from the convergence layer" section of 
the BP spec as well. Then the Bundle Authenticity parameter can be 
discussed in the BSP spec -- as an extension to the BP spec -- where it 
belongs. Very clean.

11. Re Comment.26: the security policy database has to be discussed in 
this document, where it makes sense, not in the BP spec.