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

[Scott Burleigh <[e-mail]>]

Susan F. Symington wrote:

>
>>>-- 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.
>>
> agree that the extension headers should be documented and explained in the
>security spec, but how are we going to make sure that whatever type value is
>assigned to these headers doesn't conflict with a type chosen for use in the
>bundle protocol or for use in another extension header? I was envisioning us
>placing the header types that we know of in a table in the Bundle Protocol
>so when folks make up new headers, they would be aware of which types are
>already reserved for use. If we don't have a master list of header types
>somewhere, then we at least need a master list of documents that contain all
>header types.
>
Yes, this is going to be a problem that we'll have to solve somehow.  
But I don't think having a master list in the Bundle Protocol spec is 
the answer: at some point that document is going to need to be an RFC, 
and we don't want to have to be submitting new versions of that RFC 
every time we come up with a new extension header.  Some sort of central 
naming and numbering authority is needed; if not IANA, then we'll need 
to find another or invent our own.

>>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."
>>    
>>
>This works for me but only if the BP spec is not a moving target.  If its
>paragraph numberings are going to be in flux, then this will be a royal pain
>in the neck. At this point I'd like to keep our spec as is until we are sure
>the BP spec has settled.
>  
>
Sure.  But I think we are all in agreement that it is high time for that 
spec to stop being a moving target.  Waiting until you see some evidence 
of stability is entirely reasonable, but if we're not able to achieve 
that stability pretty darn toute de suite we are going to be facing some 
trouble.

>>>- 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.
>>
>I see the merits of what you are proposing and I agree, but I'm not too
>clear on how it will work in practice at the API level given that there will
>be many different possible parameter lists that could be expected with a
>given send.request or data.indication primitive, depending on what
>combination of extension headers is in use. As the number of extension
>headers and extension protocols multiply, so does the number of possible
>different send.request primitive parameter combinations. Some document will
>have to tie these combinations together.
>
Sure, but that's an API problem rather than a spec problem.  I don't 
think it's an insoluble API problem, but I don't want to try proposing a 
solution right now; I just want to move ahead with the specs.

>>>- 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.
>>    
>>
>If folks want it in the BAH that's fine with me, but I seem to recall from
>previous meetings that there was consensus that the sender information is
>useful for more than just security and should be in the primary bundle
>header.  Debugging was one example of why it would be useful, I believe. I
>don't have any problem putting the sender field in the BAH, but before we do
>folks should think about whether they would want to know the sender even in
>cases in which security is not in use.
>
I think there have been some fairly desultory speculations that the 
sender might be helpful for some kinds of debugging, but I don't think 
there's an enthusiastic constituency for adding it to the Primary 
header.  If I hear otherwise in the next couple of days I'll work on 
inserting it.

>>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.
>>    
>>
>Do you mean that the terminology in the Bundle Security Protocol spec is
>messed up?  I actually went through and changed it according to our
>decisions of two weeks ago. I intended for it to be in conformance with what
>we decided at Berkeley, so I would appreciate specific examples of where you
>think the terminology isn't correct.
>  
>
As I say, I'm hoping the revised BP draft will help.  For example, 
though, we resolved in Berkeley that "any entity that can send and/or 
receive bundles" is a node, so in section 1.2 I would say you can't 
assert that BPA1 is the first sender and BPA2 is the first recipient.  
Since only nodes send and receive bundles, BundleNodeX is the only 
possible first sender and there needs to be a BundleNodeW living above 
BPA2 that is the first recipient.

But let's *not* get into a heated email exchange on terminology issues 
right now.  I will try to lay the terminology out in an organized 
fashion in the next edition of the spec, with rationale; let's wait 
until then to start the spilling of blood.

>>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?
>>    
>>
>Whether or not the CH remains in the bundle after decryption by the CH
>security destination is something that can be determined by security policy.
>We wanted to leave the option open to be able to keep it in if needed. Same
>with the PSH, though often it will be left in after checking because if a
>public key scheme is used to create the authenticator, many different hops
>along the way may be capable of checking the PSH value, so it would make
>sense to leave it in.
>  
>
Sure.

>>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.
>>    
>>
>
>I suppose it could be used to protect routers from replays that are destined
>specifically toward the router, but not from replays of bundles that the
>router is forwarding on to another destination.
>
Actually I think it would, precisely because of our new concept that "a 
bundle node is any entity that can send and/or receive bundles"; since a 
router is (can only be) a node like any other, it can specify 
"at-most-once-delivery" in its own registration request.  But this is 
another question on which I want *not* to engage in spirited debate 
right now.

>>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?
>>    
>>
>As Stephen's email indicated, we can code the security result as two
>separate fields: length, value, so there is no security-related need to be
>able to accommodate the very large lengths with the above SDNV. This sounds
>like a good idea to me.
>  
>
Perfect.

>>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.)
>>    
>>
>Is this just a terminology issue?  I didn't think that "canonical form"
>meant strictly the on-the-wire-format.  What we are trying to define is the
>form of the bundle that will be used to calculate the PSH.
>  
>
It probably is just a language issue, but it's one to watch out for.  If 
I was confused, it's possible that some day someone else will be too.

>>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.
>>    
>>
>I don't recall either.
>  
>
At this point I'm figuring it will be an extension header.  We all 
agreed that it was potentially useful, but so is Source Routing; it 
doesn't seem indispensable, so I don't think it belongs in the BP spec.

>>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.
>>    
>>
>Thanks.  I think what needs to be done in this situation needs to be fixed
>and made clearer.  The replayed bundle MUST be forwarded to nodes that have
>registered without the "at most once" option but MUST NOT be forwarded to
>nodes that have registered with the "at most once" option.
>  
>
That sounds right.

>>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 
>>list.
>>    
>>
>Probably a good idea.  Again, though, the question arises as to how/where
>the codes are partitioned among the protocol extensions so that a single
>code isn't used to mean two different things.
>  
>
Yep; the naming and number authority issue again.

Scott