Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
From: Scott Burleigh <[email-masked]>
To: [email-masked], [email-masked]
Date: Tue, 31 May 2005 15:03:16 -0700
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>

Michael Demmer wrote:

>As Rajesh said, the main rational for the byte savings is for small
>values. Therefore, for things we expect to be big, like crypto keys,
>we can send the length of the key first as an SDNV, then the
>value. This won't waste too much over just sending the key as an SDNV
>by itself (at most it wastes a byte or two).
>
>As such, my instinct is to just go with 1-2-3-4-5-6-7-8.
>
That sounds fine to me.

Date: Tue, 31 May 2005 14:55:51 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

As Rajesh said, the main rational for the byte savings is for small
values. Therefore, for things we expect to be big, like crypto keys,
we can send the length of the key first as an SDNV, then the
value. This won't waste too much over just sending the key as an SDNV
by itself (at most it wastes a byte or two).

As such, my instinct is to just go with 1-2-3-4-5-6-7-8. 

-m

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
To: [email-masked]
Date: Tue, 31 May 2005 16:04:08 -0400 (EDT)
Sender: [email-masked]
Reply-To: [email-masked]

> >I took a pass at changing the language from the original LTP spec to
> >match my new proposal for SDNV encodings:
> >  
> >
> This is really good, Mike.  What we still need to settle on is the 
> encoding scheme: 1-2-3-4-5-6-7-8, 1-2-3-4-5-6-8-16, 
> 1-2-4-8-16-32-64-128, or something else.  Anybody have any strong 
> feelings on this?

The case for byte-savings can be made primarily for small sizes such 
as 1,2, and 4.  OTOH, large numbers (say, up to 4096-bits) are useful
for encoding cryptographic keys.  

Say, how about:

1-2-4-8-16-128-256-512      (2^x bytes)
0-1-2-3-4-7-8-9             (x: integers congruent to {0 1 2 3 4} mod 7)

1-2-4-8-16-256-1024-8192    (2^x bytes)
0-1-2-3-4-8-10-14           (x: integers s.t. 3^x+2 is a prime)

1-2-4-8-16-256-512-1024     (2^x bytes)
0-1-2-3-4-8-9-10            (x: integers s.t. x is a sum of at most 4 cubes)

1-2-4-8-32-128-2048-8192    (2^x)
0-1-2-3-5-7-11-13           (x: 0, 1, then integers s.t. x is a prime )

See http://www.research.att.com/~njas/sequences/

Best Regards,
Rajesh

Date: Tue, 31 May 2005 10:57:11 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

Michael Demmer wrote:

>I took a pass at changing the language from the original LTP spec to
>match my new proposal for SDNV encodings:
>  
>
This is really good, Mike.  What we still need to settle on is the 
encoding scheme: 1-2-3-4-5-6-7-8, 1-2-3-4-5-6-8-16, 
1-2-4-8-16-32-64-128, or something else.  Anybody have any strong 
feelings on this?

Scott

Date: Tue, 31 May 2005 10:52:10 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
CC: "'Howard Weiss'" <[email-masked]>, "'Stephen Farrell'" <[email-masked]>
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

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

Sure.

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

Yes.

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

Yes.

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

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.

Scott

Date: Tue, 31 May 2005 10:29:41 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

I took a pass at changing the language from the original LTP spec to
match my new proposal for SDNV encodings:

---

Self-Delimiting Numeric Value (SDNV)

   The design of LTP attempts to reconcile minimal consumption of
   transmission bandwidth with

      (a) extensibility to satisfy requirements not yet identified and
      (b) scalability across a very wide range of network sizes and
          transmission payload sizes.

   A key strategic element in the design is the use of self-delimiting
   numeric values (SDNVs) that are similar in design to the Abstract
   Syntax Notation One [ASN1] encoding of data structures. An SDNV can
   be used to encode a numeric value in the range 0 .. (2^68 - 1),
   using 1 to 9 octets.

   The first octet of an SDNV -- the "discriminant" -- characterizes
   the SDNV. If the most significant bit of the discriminant is zero,
   the length of the SDNV is 1 octet and the remaining 7 bits of the
   discriminant, treated as an unsigned integer, is the value of the
   SDNV. An integer in the range of 0 to 127 can be encoded this way.

   Otherwise (if the most significant bit of the discriminant is 1),
   the next 3 bits of the discriminant encode the length of the SDNV.
   If the content of these 3 length bits, treated as an unsigned
   integer, has the value N, then N+1 additional octets are used to
   represent the value. The value is found by concatenating the
   remaining 4 bits of the discriminant with octets 2 through N+2 of
   the SDNV, and treating this result as an unsigned integer.

   The following table outlines the SDNV encoding for all value
   ranges, their associated discriminant encodings, and the total
   length in octets of the SDNV.

   Value Range         Discriminant     SDNV Length 
   ----------------    ------------     -----------
   0        127         0XXX XXXX            1
   128      4095        1000 XXXX            2
   4096     1048575     1001 XXXX            3
   2^20     2^28 - 1    1010 XXXX            4
   2^28     2^36 - 1    1011 XXXX            5
   2^36     2^44 - 1    1100 XXXX            6
   2^44     2^52 - 1    1101 XXXX            7
   2^52     2^60 - 1    1110 XXXX            8
   2^60     2^68 - 1    1111 XXXX            9

   An SDNV can therefore be used to efficiently represent both large
   and small integer values. However, SDNV is clearly not the best way
   to represent every numeric value. When the maximum possible value
   of a number is known without question, the cost of an additional 8
   bits of discriminant may not be justified. For example, an SDNV is
   a poor way to represent an integer whose value typically falls in
   the range 128 to 255.

   In general, though, we believe that SDNV representation of selected
   numeric values in LTP segments yields the smallest segment sizes
   without sacrificing scalability.

Date: Fri, 27 May 2005 15:19:26 -0400
From: Howard Weiss <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------050901090901070706060501
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

For keys, we need (at a min) 128 bits for a symmetric key and (at a min) 
1024 bits for an asymmetric key.  But the key sizes will vary - 512 bits 
may not be unheard of for a symmetric key and 2048 for an asymmetric.

Howie

Scott Burleigh wrote:

> Michael Demmer wrote:
>
>>> I don't much care one way or another.  Do we really think we're
>>> likely to need to represent numbers bigger than (2*68) - 1 in SDNVs?
>>>   
>>
>>
>> Very doubtful if all they're used for is lengths, maybe so if they're
>> used for other things like crypto keys and such.
>>
> If we think we really are going to use SDNVs for crypto keys then I 
> think 1/2/3/4/6/8/12/16 isn't going to be enough, because crypto keys 
> only seem to get longer as the years go by.  I think that would argue 
> for either the original SDNV-8 (or -16) scheme or else an encoding 
> along the lines of 1/2/4/8/16/32/64/128.
>
> If not -- that is, if we're going use ordinary LV structures (an 8-bit 
> length followed by that many bytes of content) for encryption keys -- 
> then I don't see any point in moving away from 1/2/3/4/5/6/7/8.
>
> Scott
> _______________________________________________
> dtn-dev mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-dev

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

--------------050901090901070706060501
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">For keys, we
need (at a min) 128 bits for a symmetric key and (at a min) 1024 bits
for an asymmetric key.&nbsp; But the key sizes will vary - 512 bits may not
be unheard of for a symmetric key and 2048 for an asymmetric.<br>
<br>
Howie<br>
</font></font><br>
Scott Burleigh wrote:<br>
<blockquote cite="[email-masked]" type="cite">Michael
Demmer wrote:
  <br>
  <br>
  <blockquote type="cite">
    <blockquote type="cite">I don't much care one way or another.&nbsp; Do
we really think we're
      <br>
likely to need to represent numbers bigger than (2*68) - 1 in SDNVs?
      <br>
&nbsp;&nbsp; <br>
    </blockquote>
    <br>
Very doubtful if all they're used for is lengths, maybe so if they're
    <br>
used for other things like crypto keys and such.
    <br>
    <br>
  </blockquote>
If we think we really are going to use SDNVs for crypto keys then I
think 1/2/3/4/6/8/12/16 isn't going to be enough, because crypto keys
only seem to get longer as the years go by.&nbsp; I think that would argue
for either the original SDNV-8 (or -16) scheme or else an encoding
along the lines of 1/2/4/8/16/32/64/128.
  <br>
  <br>
If not -- that is, if we're going use ordinary LV structures (an 8-bit
length followed by that many bytes of content) for encryption keys --
then I don't see any point in moving away from 1/2/3/4/5/6/7/8.
  <br>
  <br>
Scott
  <br>
_______________________________________________
  <br>
dtn-dev mailing list
  <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
  <br>
<a class="moz-txt-link-freetext" href="http://mailman.dtnrg.org/mailman/listinfo/dtn-dev">http://mailman.dtnrg.org/mailman/listinfo/dtn-dev</a>
  <br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

</pre>
</body>
</html>

--------------050901090901070706060501--

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
To: [email-masked]
Date: Thu, 26 May 2005 17:26:17 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

> > I don't much care one way or another.  Do we really think we're
> > likely to need to represent numbers bigger than (2*68) - 1 in SDNVs?
> 
> Very doubtful if all they're used for is lengths, maybe so if they're
> used for other things like crypto keys and such. 
> 
> > If so, what convinces us that we're likely to need 16 bytes but not
> > equally likely to need 128 bytes?  Certainly we can use an encoding
> > scheme like this, or lots of others (for example, 1 2 4 8 16 32 64
> > 128), but the fact that we can doesn't necessarily mean we should.
> > What's the rationale for this particular system?
> 
> Well -- mostly a gut feeling at the time that we may find 12 and 16
> more useful than 5 and 7, but I confess that I don't have any
> particular proposed use cases or concrete justification for this
> feeling. So I'm really fine either way as well.

I do not know what possible uses are being considered for SDNVs in DTNs,
but it may be worth taking a look at some common sizes of interest.

              1B Bluetooth. (B = Byte).
              4B IPv4.
              6B Ethernet.
             12D for UPC (D = decimal digit).
             13D for ISBN.  
             13D for European Article Numbering.
             15D for E.164.
             16B IPv6.
             20B ATM End System Address.     > 16 octets.
            128B 1024-bit Cryptographic keys  
            512B 4096-bit Cryptographic keys and signatures 
                 are supported by several implementations

Best Regards,
Rajesh

Date: Thu, 26 May 2005 12:09:05 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

Michael Demmer wrote:

>>I don't much care one way or another.  Do we really think we're
>>likely to need to represent numbers bigger than (2*68) - 1 in SDNVs?
>>    
>>
>
>Very doubtful if all they're used for is lengths, maybe so if they're
>used for other things like crypto keys and such.
>
If we think we really are going to use SDNVs for crypto keys then I 
think 1/2/3/4/6/8/12/16 isn't going to be enough, because crypto keys 
only seem to get longer as the years go by.  I think that would argue 
for either the original SDNV-8 (or -16) scheme or else an encoding along 
the lines of 1/2/4/8/16/32/64/128.

If not -- that is, if we're going use ordinary LV structures (an 8-bit 
length followed by that many bytes of content) for encryption keys -- 
then I don't see any point in moving away from 1/2/3/4/5/6/7/8.

Scott

Date: Thu, 26 May 2005 11:48:25 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

> I don't much care one way or another.  Do we really think we're
> likely to need to represent numbers bigger than (2*68) - 1 in SDNVs?

Very doubtful if all they're used for is lengths, maybe so if they're
used for other things like crypto keys and such. 

> If so, what convinces us that we're likely to need 16 bytes but not
> equally likely to need 128 bytes?  Certainly we can use an encoding
> scheme like this, or lots of others (for example, 1 2 4 8 16 32 64
> 128), but the fact that we can doesn't necessarily mean we should.
> What's the rationale for this particular system?

Well -- mostly a gut feeling at the time that we may find 12 and 16
more useful than 5 and 7, but I confess that I don't have any
particular proposed use cases or concrete justification for this
feeling. So I'm really fine either way as well.

-m

Date: Thu, 26 May 2005 11:31:09 -0700
From: Michael Demmer <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: are offsets enough? --was: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security	Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

> Since we now have extensions and even, apparently, criticality,
> some of those offsets might be in headers you don't know how
> to parse so the dictionary encoding has to be self-contained,
> other than whatever refers to the dictionary. Similarly, you
> cannot move stuff about in the dictionary unless you understand
> how to fix all of the headers in a bundle.

that's a good point... unless a particular node can parse and
understand all headers, then all it can do is append to the
dictionary.

-m

Date: Thu, 26 May 2005 11:27:26 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

> Michael - can you write up the paragraph that's to go
> into the LTP and/or Bundling spec and send it to the
> list?

Sure -- I'll take a whack at it.

-m

Date: Thu, 26 May 2005 08:56:31 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked], [email-masked]
Subject: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

Michael Demmer wrote:

>In talking with Kevin a bit about this, I'm gonna propose a slight
>modification to my original proposal. 
>
>For the three bits that in my original proposal indicated that there
>were 1-8 value bytes to follow, I'd say we should recast their meaning
>to be:
>
>0:   1 byte to follow
>1:   2 bytes to follow
>2:   3 bytes to follow
>3:   4 bytes to follow
>4:   6 bytes to follow
>5:   8 bytes to follow
>6:  12 bytes to follow
>7:  16 bytes to follow
>
>Basically, we drop the 5 byte and 7 byte encodings in favor of adding
>a 12 byte and a 16 byte case. 
>
>We still use the low-order nibble of the discriminator byte as the
>high order bits of the value.
>
>Thoughts?
>
I don't much care one way or another.  Do we really think we're likely 
to need to represent numbers bigger than (2*68) - 1 in SDNVs?  If so, 
what convinces us that we're likely to need 16 bytes but not equally 
likely to need 128 bytes?  Certainly we can use an encoding scheme like 
this, or lots of others (for example, 1 2 4 8 16 32 64 128), but the 
fact that we can doesn't necessarily mean we should.  What's the 
rationale for this particular system?

Scott

Date: Thu, 26 May 2005 15:02:14 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: I18N (was: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security	Protocol Spec.)
Sender: [email-masked]
Reply-To: [email-masked]

Scott Burleigh wrote:

> Michael Demmer wrote:
> 
>>> Aha!  Ok, it can work that way so long as there're no I18N
>>> problems there (there aren't, right?).
>>
>> Well -- we need to decide on what to do re I8N. My inclination is to
>> have the protocol just be in ASCII, and put the burden on the
>> application interface to go to/from some multibyte encoding when
>> interfacing with the application.
>>  
>>
> I agree: the external representation locally exposed to applications and 
> users is where the internationalization is really needed.  On the wire I 
> don't think it's useful.

I disageee - endpoint IDs are v. likely to want to include
non-ASCII characters since they'll practically be used
to name things.

Furthermore the way we're farming out identifier scheme
standardisation (via IANA or RFCs or whatever) just
increases the liklihood that I18N will be needed.

Read stringprep to see how bad it gets! Talk to Paul Hoffmann
or someone else that knows if you want to hear to pain that
iDNS invovled.

Stephen.

Date: Thu, 26 May 2005 14:58:41 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "'Michael Demmer'" <[email-masked]>
Subject: [dtn-security] Re: are offsets enough? --was: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security	Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

Since we now have extensions and even, apparently, criticality,
some of those offsets might be in headers you don't know how
to parse so the dictionary encoding has to be self-contained,
other than whatever refers to the dictionary. Similarly, you
cannot move stuff about in the dictionary unless you understand
how to fix all of the headers in a bundle.

S.

Susan F. Symington wrote:
>>Personally, I think I'd rather that dictionary entries contain
>>a length field (whatever encoding) since I've found lists of
>>null-terminated strings are a great source for implementation
>>errors.
> 
> 
> Mike: Yeah -- I just feel like it's not worth the bytes. My other thought is
> that we can infer the string lengths based on the various offsets
> scattered throughout the bundle, in other words, if all the offsets
> (i.e. src, dest, custodian, etc) were sorted, we could then infer the
> various lengths based on the differences. But this is probably harder
> to read (though more efficient) than just scanning for the null.
> 
> Susan: It occurs to me that when a bundle is fragmented, we won't always be
> able to infer the various dictionary string lengths based on the various
> offsets scattered through the bundle, because not all headers (and therefore
> not all offsets) are guaranteed to be in every fragment.  The CH and PSH are
> two examples of headers that may contain an offset but that most likely will
> not be in every fragment. In the new FLAGS field we defined last week, one
> bit is for indicating whether the header must be duplicated on all fragments
> or just the first.  So, it seems like the PSH and CH may not be the only
> examples. 
> 
> So, if terminating the strings with nulls is not sufficient, then it seems
> we need something like a length field to go along with the offset.
> 
> -susan
> 
> 
> 
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-security
> 
> 

Date: Thu, 26 May 2005 14:55:19 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

Ok then I guess I rewrite a few lines of code.

Michael - can you write up the paragraph that's to go
into the LTP and/or Bundling spec and send it to the
list?

> If we're going to go with this, and if we're going to change it in LTP 
> as well (and I don't know why not), let's just call it "SDNV".

Sure: "-new" was just a subject line not a suggested term.

Stephen.

Date: Wed, 25 May 2005 17:24:42 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

In talking with Kevin a bit about this, I'm gonna propose a slight
modification to my original proposal. 

For the three bits that in my original proposal indicated that there
were 1-8 value bytes to follow, I'd say we should recast their meaning
to be:

0:   1 byte to follow
1:   2 bytes to follow
2:   3 bytes to follow
3:   4 bytes to follow
4:   6 bytes to follow
5:   8 bytes to follow
6:  12 bytes to follow
7:  16 bytes to follow

Basically, we drop the 5 byte and 7 byte encodings in favor of adding
a 12 byte and a 16 byte case. 

We still use the low-order nibble of the discriminator byte as the
high order bits of the value.

Thoughts?

-m

From: "Susan F. Symington" <[email-masked]>
To: "'Michael Demmer'" <[email-masked]>, <[email-masked]>
Cc: "'Stephen Farrell'" <[email-masked]>
Subject: RE:are offsets enough? --was: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security	Protocol Spec.
Date: Wed, 25 May 2005 14:31:19 -0400
Sender: [email-masked]
Reply-To: [email-masked]

> Personally, I think I'd rather that dictionary entries contain
> a length field (whatever encoding) since I've found lists of
> null-terminated strings are a great source for implementation
> errors.

Mike: Yeah -- I just feel like it's not worth the bytes. My other thought is
that we can infer the string lengths based on the various offsets
scattered throughout the bundle, in other words, if all the offsets
(i.e. src, dest, custodian, etc) were sorted, we could then infer the
various lengths based on the differences. But this is probably harder
to read (though more efficient) than just scanning for the null.

Susan: It occurs to me that when a bundle is fragmented, we won't always be
able to infer the various dictionary string lengths based on the various
offsets scattered through the bundle, because not all headers (and therefore
not all offsets) are guaranteed to be in every fragment.  The CH and PSH are
two examples of headers that may contain an offset but that most likely will
not be in every fragment. In the new FLAGS field we defined last week, one
bit is for indicating whether the header must be duplicated on all fragments
or just the first.  So, it seems like the PSH and CH may not be the only
examples. 

So, if terminating the strings with nulls is not sufficient, then it seems
we need something like a length field to go along with the offset.

-susan

Date: Wed, 25 May 2005 10:25:26 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: [email-masked], "'Howard Weiss'" <[email-masked]>
Subject: Re: [dtn-dev] Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

> Anyway, I like this approach but have one caveat to offer: you
> actually can only have a maximum of 8 bytes following the
> discriminator, not 9:

Indeed you are correct -- my mistake in thinking I can be too clever
early in the morning... :)

> So the maximum value your number can have is (2**68 - 1).

This still seems big enough to me. Anyone have objections?

-m

Date: Wed, 25 May 2005 10:22:05 -0700
From: Michael Demmer <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

> If we're going to go with this, and if we're going to change it in
> LTP as well (and I don't know why not), let's just call it "SDNV".

Works for me -- so what's the plan for deciding "if we're going to go
with this"?

-m

Date: Wed, 25 May 2005 09:49:06 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
CC: "Susan F. Symington" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security	Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

Michael Demmer wrote:

>>Aha!  Ok, it can work that way so long as there're no I18N
>>problems there (there aren't, right?).
>>    
>>
>
>Well -- we need to decide on what to do re I8N. My inclination is to
>have the protocol just be in ASCII, and put the burden on the
>application interface to go to/from some multibyte encoding when
>interfacing with the application.
>  
>
I agree: the external representation locally exposed to applications and 
users is where the internationalization is really needed.  On the wire I 
don't think it's useful.

Scott

Date: Wed, 25 May 2005 09:45:45 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked], [email-masked]
Subject: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Sender: [email-masked]
Reply-To: [email-masked]

Michael Demmer wrote:

>>I don't think its really harder to code up use of
>>sdnv-8 or -16 though, nor are coders likely IMO to
>>get confused between these as long as we don't
>>oscillate between 'em at specification time.
>>    
>>
>
>Agreed -- I don't think any one of these schemes is easier and/or
>harder to implement. My argument would be to settle on any one, but as
>long as we're consistent, I don't really care. 
>
>It does, however, bring a naming question as to what to call this
>scheme... I don't think SDNV-new is all that appealing in the long
>run.
>
If we're going to go with this, and if we're going to change it in LTP 
as well (and I don't know why not), let's just call it "SDNV".

Date: Wed, 25 May 2005 09:43:12 -0700
From: Scott Burleigh <[email-masked]>
CC: [email-masked], [email-masked], "'Howard Weiss'" <[email-masked]>
Subject: Re: [dtn-dev] Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

Michael Demmer wrote:

>One thing that may be relevant to the security discussion (and to
>dtn-dev in general) is that I think we should use a different SDNV
>format than the ones described in the LTP spec (i.e. neither SDNV-8
>nor SDNV-16).
>
>Here's my proposal:
>
>If the value to be encoded is <= 127, then the high-order bit of the
>discriminator is set to zero and the remaining 7 bits encode the
>value. This is unchanged from the existing SDNV-8 format.
>
>If the value is larger than 127, then the high-order bit of the
>discriminator is set to one, the next three bits indicate how many
>length bytes there are, and the next four bits encode the high-order
>nibble of the length value. Since there must be at least one
>subsequent byte to encode the length (implied since the high order bit
>is one), then we can use the three bits to indicate 1-9 bytes of
>length that follow.
>  
>
I started off with an SDNV design that worked like this, years ago, and 
can't remember why I moved away from it in the early LTP specs; maybe 
because at that time I wanted to have a sign bit int the discriminator 
as well, and that didn't leave enough bits in the high-order nibble to 
encode the length.  (Or because we wanted to encode the encryption keys 
themselves as SDNVs, since they're numbers, and this approach didn't 
support long enough numbers.)  Anyway, I like this approach but have one 
caveat to offer: you actually can only have a maximum of 8 bytes 
following the discriminator, not 9:

Length bits      Indicated length
-----------      ----------------
000                  1
001                  2
010                  3
011                  4
100                  5
101                  6
110                  7
111                  8

So the maximum value your number can have is (2**68 - 1).

>For some concreteness, the value ranges and number of bytes needed to
>encode them are:
>
>0       - 127		1 byte
>128     - 4095		2 bytes
>4096    - 1048675	3 bytes
>1048576 - 268435455	4 bytes
>...
>
>The attractive thing to me about this is that since we're going to use
>one of these to encode the length of each header, then it's likely
>that most of the time, either one or two bytes will do. In contrast,
>an SDNV-8 requires three bytes (one discriminator and two length) for
>all values between 256 and 65536. So really, what we're talking about
>is the range between 256 and 4096, which actually seems pretty likely
>to occur.
>
>Now, as I can see it, the only drawback of this approach versus either
>the SDNV-8 or SDNV-16 is that it has only 4 + (9 * 8) = 76 bits for
>the length encoding. This seems more than sufficient for any expected
>value, as the maximum value is 7.5 x 10^22, which is big enough that I
>don't even know the word for it. (Out of curiosity, does anyone know
>if there is a prefix like peta- or tera- for that size number?)
>  
>
Actually only 68 bits.

>Finally, while in some cases, it can be argued that using one of the
>other encodings may save a byte in the average case, for
>implementation and specification clarity, I would advocate that all
>bundle protocols that use SDNVs should use the same one (this one).
>
I agree with Stephen that it's actually not all that tough to keep 
SDNV-8 vs SDNV-16 straight, but I too am happy with this approach if 
it's our consensus.

Scott

Date: Wed, 25 May 2005 09:39:45 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security	Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

> Aha!  Ok, it can work that way so long as there're no I18N
> problems there (there aren't, right?).

Well -- we need to decide on what to do re I8N. My inclination is to
have the protocol just be in ASCII, and put the burden on the
application interface to go to/from some multibyte encoding when
interfacing with the application.

> Personally, I think I'd rather that dictionary entries contain
> a length field (whatever encoding) since I've found lists of
> null-terminated strings are a great source for implementation
> errors.

Yeah -- I just feel like it's not worth the bytes. My other thought is
that we can infer the string lengths based on the various offsets
scattered throughout the bundle, in other words, if all the offsets
(i.e. src, dest, custodian, etc) were sorted, we could then infer the
various lengths based on the differences. But this is probably harder
to read (though more efficient) than just scanning for the null.

-m

Date: Wed, 25 May 2005 09:37:07 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: SDNV-new (was: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.)
Sender: [email-masked]
Reply-To: [email-masked]

> I guess this could work ok. Whether its better or worse
> than sdnv-8/sdnv-16 depends on the frequency with which
> we're encoding values in the range 4096-65535, 

Actually, not quite. See below...

> and of course, my code currently does the -8/-16 thing, so if
> we're making this change, we'll want to do it in LTP
> at the same time.

That'd be fine with me of course.

> Also - can you give some more examples of values
> and how they're encoded - the description is a bit
> opaque.

Ok, here's some arbitrary examples that express some of the various
cases. Note that for the discriminator byte of the SDNV binary, I put
in a .  character to separate the relevant pieces.

value	       hex	SDNV hex	SDNV binary
10             0a       0a              0.000.1010
90             5a       5a              0.101.1010
197	       c5	80 c5		1.000.0000 11000101
2099	       833	88 33		1.000.1000 00110011
12345	       3039	90 30 39	1.001.0000 00110000 00111001
456789	       6f855    96 f8 55	1.001.0110 11111000 01010101
123456789      75bcd15  a7 5b cd 15     1.010.0111 01011011 11001101 00010101

So, as I see it, the relevant range is for the values like 2099,
456789, etc in which we encode the high-order nibble in the
discriminator byte itself. With SDNV-8, the value 2099 requires three
bytes, whereas with this scheme it requires only two. Similarly,
456789 would require four bytes with SDNV-8, but only three with this
scheme, etc.

> I don't think its really harder to code up use of
> sdnv-8 or -16 though, nor are coders likely IMO to
> get confused between these as long as we don't
> oscillate between 'em at specification time.

Agreed -- I don't think any one of these schemes is easier and/or
harder to implement. My argument would be to settle on any one, but as
long as we're consistent, I don't really care. 

It does, however, bring a naming question as to what to call this
scheme... I don't think SDNV-new is all that appealing in the long
run.

-m

Date: Wed, 25 May 2005 12:05:37 -0400
From: Wesley Eddy <[email-masked]>
To: [email-masked]
Cc: [email-masked], "Susan F. Symington" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

--oLBj+sq0vYjzfsbl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 25, 2005 at 08:20:06AM -0700, Michael Demmer wrote:
>=20
> One thing that may be relevant to the security discussion (and to
> dtn-dev in general) is that I think we should use a different SDNV
> format than the ones described in the LTP spec (i.e. neither SDNV-8
> nor SDNV-16).
>=20
> Here's my proposal:
>
> ...

I like this idea.  Reading the LTP spec, it struck me as odd (and
slightly ugly) that there were 2 different types of SDNV.  I couldn't
instantly think of any good way to "unify" them though, so I didn't
gripe about it.  Now that there's a proposed alternative, I'll record
my gripe with the dual-format SDNVs.

-Wes=20

--=20
Wesley M. Eddy
Verizon FNS / NASA GRC
http://roland.grc.nasa.gov/~weddy

--oLBj+sq0vYjzfsbl--

Date: Wed, 25 May 2005 16:49:23 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked], [email-masked]
Subject: SDNV-new (was: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.)
Sender: [email-masked]
Reply-To: [email-masked]

Michael,

I guess this could work ok. Whether its better or worse
than sdnv-8/sdnv-16 depends on the frequency with which
we're encoding values in the range 4096-65535, and of
course, my code currently does the -8/-16 thing, so if
we're making this change, we'll want to do it in LTP
at the same time.

Also - can you give some more examples of values
and how they're encoded - the description is a bit
opaque.

I don't think its really harder to code up use of
sdnv-8 or -16 though, nor are coders likely IMO to
get confused between these as long as we don't
oscillate between 'em at specification time.

All in all, I'd be for not changing since I've got
code, but, I've no problem changing to this if
that's the concensus.

Cheers,
Stephen.

Michael Demmer wrote:

> One thing that may be relevant to the security discussion (and to
> dtn-dev in general) is that I think we should use a different SDNV
> format than the ones described in the LTP spec (i.e. neither SDNV-8
> nor SDNV-16).
> 
> Here's my proposal:
> 
> If the value to be encoded is <= 127, then the high-order bit of the
> discriminator is set to zero and the remaining 7 bits encode the
> value. This is unchanged from the existing SDNV-8 format.
> 
> If the value is larger than 127, then the high-order bit of the
> discriminator is set to one, the next three bits indicate how many
> length bytes there are, and the next four bits encode the high-order
> nibble of the length value. Since there must be at least one
> subsequent byte to encode the length (implied since the high order bit
> is one), then we can use the three bits to indicate 1-9 bytes of
> length that follow.
> 
> For some concreteness, the value ranges and number of bytes needed to
> encode them are:
> 
> 0       - 127		1 byte
> 128     - 4095		2 bytes
> 4096    - 1048675	3 bytes
> 1048576 - 268435455	4 bytes
> ...
> 
> The attractive thing to me about this is that since we're going to use
> one of these to encode the length of each header, then it's likely
> that most of the time, either one or two bytes will do. In contrast,
> an SDNV-8 requires three bytes (one discriminator and two length) for
> all values between 256 and 65536. So really, what we're talking about
> is the range between 256 and 4096, which actually seems pretty likely
> to occur.
> 
> Now, as I can see it, the only drawback of this approach versus either
> the SDNV-8 or SDNV-16 is that it has only 4 + (9 * 8) = 76 bits for
> the length encoding. This seems more than sufficient for any expected
> value, as the maximum value is 7.5 x 10^22, which is big enough that I
> don't even know the word for it. (Out of curiosity, does anyone know
> if there is a prefix like peta- or tera- for that size number?)
> 
> Finally, while in some cases, it can be argued that using one of the
> other encodings may save a byte in the average case, for
> implementation and specification clarity, I would advocate that all
> bundle protocols that use SDNVs should use the same one (this one).
> 
> -m
> 
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-security
> 
> 

Date: Wed, 25 May 2005 16:48:39 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security	Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

> The dictionary part is a blob of consecutive null-terminated
> strings 

Aha!  Ok, it can work that way so long as there're no I18N
problems there (there aren't, right?).

Personally, I think I'd rather that dictionary entries contain
a length field (whatever encoding) since I've found lists of
null-terminated strings are a great source for implementation
errors.

S.

Date: Wed, 25 May 2005 08:37:39 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security	Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

> I guess that that's possible, but I'd be for getting started
> without the dictionary and changing to use it later if it
> makes sense than.

That'd be ok with me I guess -- though for the reference
implementation at least, it should be pretty easy to use it since I'll
have helper functions and the like for stuffing URIs in and out of the
dictionary.

> But since you've suggested it: what's the easy way to encode
> the optional src and/or optional dest optionally using the
> dictionary? (I'm just not up to speed on how the dictionary
> encoding currently works.)

The dictionary part is a blob of consecutive null-terminated
strings of total length <= 64K. Encoding a scheme:ssp is therefore a
pair of offsets, one for the scheme and one for the ssp, that indicate
the first byte of the string in the dictionary.

-m

From: "Susan F. Symington" <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>
Cc: <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: RE: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Date: Wed, 25 May 2005 11:36:50 -0400
Sender: [email-masked]
Reply-To: [email-masked]

Stephen,

1. One of the decisions that was made at the Berkeley meetings last week was
that the dictionary header would contain all endpoint ids (EIDs) that appear
in the bundle header, including the four in the primary bundle header, any
security-related EIDs, any EIDs used in a source route header, etc.

I understand your point that the security EIDs are only present in the
security headers if they are different from the source and destination EIDs.
At first I agreed with you that there would therefore be no gain in using
the dictionary header for the security EIDs. However, after thinking about
it I think that it makes sense to use the dictionary header, as decided. For
one thing, a security EID might be the same as a report-to EID. Furthermore,
if a source route header does eventually get defined, a security source or
destination may very well be the same as an EID in the source route. So, I
think there may be good reason to have the PSH-security-source and other
security fields be offsets into the dictionary header than self-contained
SDNVs.

2. Also according to last week's discussions, EIDs will be represented as a
pair of two-byte offsets in the dictionary: one byte for scheme and 1 byte
for SSP (Scheme-specific-part). If we do use the dictionary then is there
still something wrong with the encoding?  I'm not sure I see it. I don't
think there is both and offset and length to mark the start and end of each
string in the dictionary.  I believe that we are using only offsets, with
the end of each string being determined by the start of the next. (Now that
I think about it, this may be a pain (but still doable) if the offsets are
coming from lots of different headers, and not just the primary bundle
header, but that's not a security issue; its an issue of how to structure
the pointers into the dictionary header.) If there is still something wrong
with the encoding, can you please explain it?

3. Even if there is nothing incorrect about the current encoding, it seems
like we will want to make the ciphersuite field bigger. Do you want to do it
now?

-susan

*****************************************************************
PLEASE NOTE: The exchange for Susan Symington's work numbers has changed
from "883" to "983". So, her new office contact information is now:
 
703-983-7209 (voice)
708-983-7142 (fax)
 
Please make a note of this change. Thanks!
******************************************************************

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 5:57 AM
To: Susan F. Symington
Cc: [email-masked]; 'Howard Weiss'
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.

Hi Susan,

I think that this is fine to go, but I believe there
was one change discussed last week that might be
worth getting into the -00 version, since as currently
written the encoding doesn't quite work;-)

The current text uses 3 bits of the ciphersuite ID to
indicate presence/absence of the of src/dest/parms.

It appears (from last week's chats) that each of these is
better encoded as SDNVs contained in the BAH,PSH or CH
(since src/dest are only present when not the same as
something already present/known, so there's no major
gain in using the dictionary header). Given that, then
we can use '00'H to indicate absence at the cost of 3
bytes, but if we're adding a BAH,PSH or CH the overall
cost is probably so high that the additional 3 bytes
are acceptable.

That also solves the ciphersuite ID-size issue
since 5 bits isn't really enough, but 8 bits
probably is.

If the 3 byte overhead (call that plan A) isn't
acceptable, then I'd suggest we try plan B:

a) make the change to use SDNV-8 for src & dest and
    not use the dictionary header for these,
b) make the ciphersuite ID a 16-bit field, with the
    top three bits used for presence/absence of
    src/dest/parms, with maybe another 3 bits
    reserved and a 10-bit ciphersuite ID.

That'd involve a 1-byte overhead on all messages,
but makes messages that contain a src, dest &
parms a byte bigger than otherwise.

(I don't mind which plan we go with for now. I
suppose plan B is very slightly better since we
get those "reserved" bits:-)

All the changes for this are contained in section
3.1 since later sections always (hopefully) talk
about the fields being present/absent without getting
into encoding details.

So, if you've time before posting, I think it'd be
worthwhile, but as I say, its ok as-is for a -00 IMO.
(If you're stuck for time but want the change, you
can fire over the xml and I'll do the editing.)

Regards,
Stephen.

PS: The reason the current encoding doesn't work is that
as I understand it the "natural" encoding of endpoint
IDs can use the dictionary header so as written we're
missing some offset/length field to allow the decoder
to spot the end of the src field/start of the dest field
when both are present.

Date: Wed, 25 May 2005 16:32:49 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

Michael,

I guess that that's possible, but I'd be for getting started
without the dictionary and changing to use it later if it
makes sense than.

But since you've suggested it: what's the easy way to encode
the optional src and/or optional dest optionally using the
dictionary? (I'm just not up to speed on how the dictionary
encoding currently works.)

Stephen.

Michael Demmer wrote:
> I must confess that I have as of yet only skimmed the document, but
> I'd like to put a vote in against not using the dictionary
> header. 
> 
> While it may save a byte or two when encoding the length of the
> string, I'm betting that in the average case, the schemas of the PSH
> src/dest will overlap with something in the primary header so you're
> better off using the dictionary.
> 
> -m
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-security
> 
> 

Date: Wed, 25 May 2005 08:23:59 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

I must confess that I have as of yet only skimmed the document, but
I'd like to put a vote in against not using the dictionary
header. 

While it may save a byte or two when encoding the length of the
string, I'm betting that in the average case, the schemas of the PSH
src/dest will overlap with something in the primary header so you're
better off using the dictionary.

-m

Date: Wed, 25 May 2005 08:20:06 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked], [email-masked]
Cc: "Susan F. Symington" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

One thing that may be relevant to the security discussion (and to
dtn-dev in general) is that I think we should use a different SDNV
format than the ones described in the LTP spec (i.e. neither SDNV-8
nor SDNV-16).

Here's my proposal:

If the value to be encoded is <= 127, then the high-order bit of the
discriminator is set to zero and the remaining 7 bits encode the
value. This is unchanged from the existing SDNV-8 format.

If the value is larger than 127, then the high-order bit of the
discriminator is set to one, the next three bits indicate how many
length bytes there are, and the next four bits encode the high-order
nibble of the length value. Since there must be at least one
subsequent byte to encode the length (implied since the high order bit
is one), then we can use the three bits to indicate 1-9 bytes of
length that follow.

For some concreteness, the value ranges and number of bytes needed to
encode them are:

0       - 127		1 byte
128     - 4095		2 bytes
4096    - 1048675	3 bytes
1048576 - 268435455	4 bytes
...

The attractive thing to me about this is that since we're going to use
one of these to encode the length of each header, then it's likely
that most of the time, either one or two bytes will do. In contrast,
an SDNV-8 requires three bytes (one discriminator and two length) for
all values between 256 and 65536. So really, what we're talking about
is the range between 256 and 4096, which actually seems pretty likely
to occur.

Now, as I can see it, the only drawback of this approach versus either
the SDNV-8 or SDNV-16 is that it has only 4 + (9 * 8) = 76 bits for
the length encoding. This seems more than sufficient for any expected
value, as the maximum value is 7.5 x 10^22, which is big enough that I
don't even know the word for it. (Out of curiosity, does anyone know
if there is a prefix like peta- or tera- for that size number?)

Finally, while in some cases, it can be argued that using one of the
other encodings may save a byte in the average case, for
implementation and specification clarity, I would advocate that all
bundle protocols that use SDNVs should use the same one (this one).

-m

Date: Wed, 25 May 2005 10:57:03 +0100
From: Stephen Farrell <[email-masked]>
To: "Susan F. Symington" <[email-masked]>
Cc: [email-masked], "'Howard Weiss'" <[email-masked]>
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

Hi Susan,

I think that this is fine to go, but I believe there
was one change discussed last week that might be
worth getting into the -00 version, since as currently
written the encoding doesn't quite work;-)

The current text uses 3 bits of the ciphersuite ID to
indicate presence/absence of the of src/dest/parms.

It appears (from last week's chats) that each of these is
better encoded as SDNVs contained in the BAH,PSH or CH
(since src/dest are only present when not the same as
something already present/known, so there's no major
gain in using the dictionary header). Given that, then
we can use '00'H to indicate absence at the cost of 3
bytes, but if we're adding a BAH,PSH or CH the overall
cost is probably so high that the additional 3 bytes
are acceptable.

That also solves the ciphersuite ID-size issue
since 5 bits isn't really enough, but 8 bits
probably is.

If the 3 byte overhead (call that plan A) isn't
acceptable, then I'd suggest we try plan B:

a) make the change to use SDNV-8 for src & dest and
    not use the dictionary header for these,
b) make the ciphersuite ID a 16-bit field, with the
    top three bits used for presence/absence of
    src/dest/parms, with maybe another 3 bits
    reserved and a 10-bit ciphersuite ID.

That'd involve a 1-byte overhead on all messages,
but makes messages that contain a src, dest &
parms a byte bigger than otherwise.

(I don't mind which plan we go with for now. I
suppose plan B is very slightly better since we
get those "reserved" bits:-)

All the changes for this are contained in section
3.1 since later sections always (hopefully) talk
about the fields being present/absent without getting
into encoding details.

So, if you've time before posting, I think it'd be
worthwhile, but as I say, its ok as-is for a -00 IMO.
(If you're stuck for time but want the change, you
can fire over the xml and I'll do the editing.)

Regards,
Stephen.

PS: The reason the current encoding doesn't work is that
as I understand it the "natural" encoding of endpoint
IDs can use the dictionary header so as written we're
missing some offset/length field to allow the decoder
to spot the end of the src field/start of the dest field
when both are present.

From: "Susan F. Symington" <[email-masked]>
To: <[email-masked]>
Cc: "'Howard Weiss'" <[email-masked]>, "'Stephen Farrell'" <[email-masked]>
Date: Tue, 24 May 2005 14:54:49 -0400
Subject: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_012C_01C56070.88C0FD80
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_012D_01C56070.88C0FD80"

------=_NextPart_001_012D_01C56070.88C0FD80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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.
 
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
- need to remove text about authenticating the BAH from the bundle
processing steps
- need to remove BAH and PSH header format descriptions
- need an at-most-once delivery parameter of the Register.request primitive
- need to remove the primary bundle header security flags field
- need to add a sender field to the primary bundle header 
- 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
- need modifications to the send.Request and Data.Indication Delivery
Options Security parameters to 
  be able to pass appropriate parameter (e.g., ciphersuite parameters)
 
Thanks for your interest,
susan

------=_NextPart_001_012D_01C56070.88C0FD80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2627" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D119274318-24052005>All,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D119274318-24052005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D119274318-24052005>Attached is our=20
first draft of the DTN Bundle Security Protocol Specification. Please =
read it=20
and provide comments. Ideally we would like to have an 01 draft =
available by mid=20
July, in time to be considered at the next IETF meeting, so we would =
appreciate=20
receiving your comments in time to be considered for the next=20
draft.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D119274318-24052005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D119274318-24052005>This&nbsp;Bundle=20
Security Protocol &nbsp;will require the following changes to the base =
Bundle=20
Protocol Specification:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D119274318-24052005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D119274318-24052005>- need =
a Statment in=20
the Bundle Protocol that&nbsp;<FONT face=3D"Times New Roman" size=3D3> =
security is=20
RECOMMENDED to implement and OPTIONAL to use</FONT>
<DIV v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: 111%">
<DIV class=3DO1=20
style=3D"mso-line-spacing: '-144 -40 -80'; mso-margin-left-alt: 358; =
mso-text-indent-alt: 215"><SPAN=20
style=3D"LEFT: -3.11%; COLOR: #fdaa03; POSITION: absolute; =
mso-special-format: bullet">&#8211;</SPAN></SPAN>-=20
need a new Confidentiality header type<BR>-&nbsp;<SPAN=20
class=3D119274318-24052005>need to </SPAN>remove text about=20
authenticating&nbsp;<SPAN class=3D119274318-24052005>the </SPAN>BAH from =
the=20
bundle&nbsp;<SPAN class=3D119274318-24052005>processing=20
steps</SPAN><BR>-&nbsp;<SPAN class=3D119274318-24052005>need to =
</SPAN>remove BAH=20
and PSH header format descriptions<BR>- need an at-most-once delivery =
parameter=20
of&nbsp;<SPAN class=3D119274318-24052005>the </SPAN>Register.request=20
primitive<BR>-&nbsp;<SPAN class=3D119274318-24052005>need to remove=20
the</SPAN>&nbsp;primary bundle header security flags =
field<BR>-&nbsp;<SPAN=20
class=3D119274318-24052005>need to </SPAN><SPAN =
class=3D119274318-24052005>add=20
a</SPAN> sender field<SPAN class=3D119274318-24052005> to the primary =
bundle=20
header</SPAN>&nbsp;</DIV>
<DIV class=3DO1=20
style=3D"mso-line-spacing: '-144 -40 -80'; mso-margin-left-alt: 358; =
mso-text-indent-alt: 215"></SPAN></FONT><FONT=20
face=3DArial size=3D2><SPAN class=3D119274318-24052005>- in description =
of forwarding=20
steps, need to put the endpoint ID of the </SPAN></FONT><FONT =
face=3DArial=20
size=3D2><SPAN class=3D119274318-24052005>sending bundle protocol agent =
into=20
</SPAN></FONT></DIV>
<DIV class=3DO1=20
style=3D"mso-line-spacing: '-144 -40 -80'; mso-margin-left-alt: 358; =
mso-text-indent-alt: 215"><FONT=20
face=3DArial size=3D2><SPAN class=3D119274318-24052005>&nbsp; the =
dictionary=20
(if&nbsp;&nbsp; it's not already </SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
class=3D119274318-24052005>there) and place its offset in the sender =
field before=20
forwarding the bundle<BR>- need modifications to the send.Request and=20
Data.Indication Delivery </SPAN></FONT><FONT face=3DArial size=3D2><SPAN =

class=3D119274318-24052005>Options Security parameters to =
</SPAN></FONT></DIV>
<DIV class=3DO1=20
style=3D"mso-line-spacing: '-144 -40 -80'; mso-margin-left-alt: 358; =
mso-text-indent-alt: 215"><FONT=20
face=3DArial size=3D2><SPAN class=3D119274318-24052005>&nbsp; be able to =
pass=20
appropriate parameter (e.g., </SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
class=3D119274318-24052005>ciphersuite =
parameters)</SPAN></FONT></DIV></DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D119274318-24052005>Thanks =
for your=20
interest,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D119274318-24052005>susan</SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_001_012D_01C56070.88C0FD80--

------=_NextPart_000_012C_01C56070.88C0FD80
Content-Type: text/plain;
	name="DTNSecSpec-20050524.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="DTNSecSpec-20050524.txt"

DTN Research Group                                          S. Symington
Internet-Draft                                     The MITRE Corporation
Expires: November 25, 2005                                    S. Farrell
                                                  Trinity College Dublin
                                                                H. Weiss
                                                            SPARTA, Inc.
                                                            May 24, 2005

                 Bundle Security Protocol Specification
                  draft-irtf-dtnrg-bundle-security-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This document defines the bundle security protocol, which provides
   data integrity and confidentiality services.  We also describe
   various bundle security considerations including policy options.

Symington, et al.       Expires November 25, 2005               [Page 1]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Related Documents  . . . . . . . . . . . . . . . . . . . .  5
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Security-Specific Bundle Service Primitives and Parameters . .  8
     2.1   The Delivery Options Parameter . . . . . . . . . . . . . .  8
     2.2   Data indications . . . . . . . . . . . . . . . . . . . . .  9
     2.3   The At-Most-Once-Delivery Option . . . . . . . . . . . . .  9
   3.  Security Headers . . . . . . . . . . . . . . . . . . . . . . . 11
     3.1   Abstract Security Header . . . . . . . . . . . . . . . . . 11
     3.2   Bundle Authentication Header . . . . . . . . . . . . . . . 13
     3.3   Payload Security Header  . . . . . . . . . . . . . . . . . 13
     3.4   Confidentiality Header . . . . . . . . . . . . . . . . . . 14
     3.5   PSH and CH combinations  . . . . . . . . . . . . . . . . . 14
   4.  Security Processing  . . . . . . . . . . . . . . . . . . . . . 15
     4.1   Bundle Transmission Requests . . . . . . . . . . . . . . . 15
     4.2   Canonicalisation of bundles  . . . . . . . . . . . . . . . 16
     4.3   Creating a Confidentiality Header  . . . . . . . . . . . . 18
     4.4   Creating the Payload Security Header . . . . . . . . . . . 19
     4.5   Creating the Bundle Authentication Header  . . . . . . . . 19
     4.6   Bundles received from other bundle protocol agents . . . . 19
     4.7   Local Bundle Delivery  . . . . . . . . . . . . . . . . . . 20
     4.8   Optionally checking for Replays  . . . . . . . . . . . . . 20
     4.9   Bundle Forwarding  . . . . . . . . . . . . . . . . . . . . 21
     4.10  Bundle Fragmentation and Reassembly  . . . . . . . . . . . 22
     4.11  Custodial Retransmission and Release . . . . . . . . . . . 23
     4.12  Bundle Status Report Status Flags  . . . . . . . . . . . . 23
     4.13  Convergence Layer Security Services  . . . . . . . . . . . 23
   5.  Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 24
     5.1   EntireBundleHMAC Ciphersuite . . . . . . . . . . . . . . . 24
       5.1.1   Ciphersuite Parameters . . . . . . . . . . . . . . . . 24
     5.2   HeadOfBundleHMAC Ciphersuite . . . . . . . . . . . . . . . 24
       5.2.1   Ciphersuite Parameters . . . . . . . . . . . . . . . . 25
     5.3   EntireBundleSig Ciphersuite  . . . . . . . . . . . . . . . 25
       5.3.1   Ciphersuite Parameters . . . . . . . . . . . . . . . . 25
     5.4   HeadOfBundleSig Ciphersuite  . . . . . . . . . . . . . . . 25
       5.4.1   Ciphersuite Parameters . . . . . . . . . . . . . . . . 26
     5.5   CombinationSig Ciphersuite . . . . . . . . . . . . . . . . 26
       5.5.1   Ciphersuite Parameters . . . . . . . . . . . . . . . . 26
     5.6   EntireBundleMAC  . . . . . . . . . . . . . . . . . . . . . 26
       5.6.1   Ciphersuite Parameters . . . . . . . . . . . . . . . . 27
     5.7   TP-type Ciphersuites . . . . . . . . . . . . . . . . . . . 27
       5.7.1   Ciphersuite Parameters . . . . . . . . . . . . . . . . 27
   6.  Default Values . . . . . . . . . . . . . . . . . . . . . . . . 28
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
       Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 36

Symington, et al.       Expires November 25, 2005               [Page 2]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36
       Intellectual Property and Copyright Statements . . . . . . . . 37

Symington, et al.       Expires November 25, 2005               [Page 3]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].

   This document defines security features for the bundle protocol [2]
   intended for use in delay tolerant networks, in order to provide the
   DTN security services as described in the DTN Security Overview and
   Motivations document [3].

   The bundle protocol is used in DTNs which overlay on top of multiple
   networks, some of which are challenged by limitations such as
   intermittent and possibly unpredictable loss of connectivity, long or
   variable delay, asymmetric data rates, and high error rates.  The
   purpose of the bundle protocol is to support interoperability across
   such stressed networks.  The bundle protocol is layered on top of
   underlay-network-specific convergence layers, on top of
   network-specific lower layers, to enable an application in one
   network to communicate with an application in another network, both
   of which are spanned by the DTN.

   Security will be important for the bundle protocol.  The stressed
   environment of the underlying networks over which the bundle protocol
   will operate makes it important that the DTN be protected from
   unauthorized use, and this stressed environment poses unique
   challenges on the mechanisms needed to secure the bundle protocol.
   Furthermore, DTNs may very likely be deployed in environments where a
   portion of the network might become compromised, posing the usual
   security challenges related to confidentiality, integrity and
   availability.

   The security features described in this document are RECOMMENDED for
   deployment with the Bundle Protocol.  Bundle Protocol implementations
   SHOULD support these features, except where they cannot, e.g.  due to
   processor or bandwidth constraints.  [Comment.1]

   Implementation of these security features is not mandatory because it
   is recognized that some bundle nodes will be so constrained that they
   are simply unable to use the mechanisms defined here.  For example,
   if a communications subsystem is limited to emitting 40-byte
   segments, then we cannot use a 2048-bit RSA signature to secure such
   segments.

   The implications of omitting or not using these security features
   however, need to be fully understood, especially with regard to the
   ability of an implementation to interact with bundle protocol
   implementations that do implement security and that may be configured

Symington, et al.       Expires November 25, 2005               [Page 4]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   to require that incoming bundles include specific security headers.
   [Comment.2]

 1.1   Related Documents

   This document is best read and understood within the context of the
   following other DTN documents: [Comment.3]
      The Delay-Tolerant Network Architecture [4] defines the
      architecture for delay-tolerant networks, but does not discuss
      security at any length.
      The DTN Bundle Protocol [2] defines the format and processing of
      the headers used to implement the bundle protocol, excluding the
      security-specific headers defined here.
      The Delay-Tolerant Network Security Overview and Motivations [3]
      document provides an informative overview and high-level
      description of DTN security; it defines a security architecture
      for DTNs by describing the aspects of the DTN architecture
      requiring protection and the security mechanisms that can be used
      to provide this protection, along with motivating rationale.

1.2  Terminology

   We introduce the following terminology for purposes of clarity:
      source - the bundle node (application, bundle protocol agent,
      etc.) from which the application data unit originates
      destination - the bundle node (application, bundle protocol agent,
      etc.) to which the application data unit is ultimately destined
      sender - the bundle protocol agent that forwarded the bundle on
      its most recent hop
      recipient or "next hop" - the neighboring bundle protocol agent to
      which a sender forwards a bundle.
   [Comment.4]

   In the figure below, which is adapted from figure 1 in the Bundle
   Protocol Specification [2], four bundle protocol agents (denoted BPA
   1, BPA 2, BPA 3, and BPA 4) that implement the bundle protocol reside
   above some transport layer(s).  Three distinct transport and network
   protocols (denoted T1/N1, T2/N2, and T3/N3) are also shown.  Bundle
   protocol agents BPA 1 and BPA 4 expose the bundle service interface
   to BundleNodeX and BundleNodeY, respectively.

Symington, et al.       Expires November 25, 2005               [Page 5]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   +-----------+                                         +-----------+
   |BundleNodeX|                                         |BundleNodeY|
   +---------v-|   +->>>>>>>>>>v-+     +->>>>>>>>>>v-+   +-^---------+
   |BPA 1    v |   | ^   BPA 2 v |     | ^   BPA 3 v |   | ^  BPA 4  |
   +---------v-+   +-^---------v-+     +-^---------v-+   +-^---------+
   |Trans1   v |   + ^  T1/T2  v |     + ^  T2/T3  v |   | ^  Trans3 |
   +---------v-+   +-^---------v-+     +-^---------v +   +-^---------+
   |Net1     v |   | ^  N1/N2  v |     | ^  N2/N3  v |   | ^  Net3   |
   +---------v-+   +-^---------v +     +-^---------v-+   +-^---------+
   |         >>>>>>>>^         >>>>>>>>>>^         >>>>>>>>^         |
   +-----------+   +------------+      +-------------+   +-----------+
   |                     |                    |                      |
   |<--  An Internet --->|                    |<--- An Internet  --->|
   |                     |                    |                      |

   BPA =3D "Bundle Protocol Agent"--the implementation of the bundle
          protocol at the bundle layer

   The protocol stacks on four DTN nodes.

                                Figure 1

   Bundle node "BundleNodeX" originates data that is sent to its
   underlying bundle protocol agent BPA1.  That data is formatted into a
   bundle and forwarded to BPA2, BPA3, and BPA4 and then transmitted up
   to bundle node "BundleNodeY".  BundleNodeX is the source and
   BundleNodeY is the destination for this data.  BPA1 is the first
   sender, and BPA2 is the first recipient; BPA2 then becomes the
   sender, and BPA3 the recipient; BPA3 then becomes the last sender,
   and BPA4 the last recipient.

   If bundle protocol agent BPA1 originates data (for example, an
   administrative payload such as a bundle status report or custodial
   signal), which is then forwarded on to BPA2, BPA3, and finally BPA4,
   then BPA1 is the source of the bundle (as well as being the first
   sender of the bundle) and BPA4 is the destination of the bundle (as
   well as being the final recipient).

   We introduce the following security-specific DTN terminology:
   [Comment.5][Comment.6]
      security-source - a bundle node that adds an "end-to-end" security
      header
      security-destination - a bundle node that processes an
      "end-to-end" security header

   Referring to figure 1 again:

   If the bundle that originates at BundleNodeX as source is given a

Symington, et al.       Expires November 25, 2005               [Page 6]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   Payload Security Header (PSH) by BPA1, then BPA1 is the
   security-source of this bundle, even though BundleNodeX is its
   source.

   If the bundle that originates at BundleNodeX as source is given a
   Payload Security Header (PSH) by BPA2, then BPA2 is the
   security-source of this bundle, even though BundleNodeX is its
   source.

   If the bundle that originates at BundleNodeX as source is given a
   Confidentiality Header (CH) by BPA1 protected using a key held by
   BPA2, then the BPA1 is the security-source of this bundle, and BPA-2
   is the security destination.

Symington, et al.       Expires November 25, 2005               [Page 7]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

2.  Security-Specific Bundle Service Primitives and Parameters

2.1  The Delivery Options Parameter
   [Comment.7][Comment.8]

   The bundle service consumes a Send.request primitive that is used by
   the bundle node to request transmission of an application data unit
   from the source bundle endpoint to a destination bundle endpoint.
   One of the parameters of this primitive is "delivery options".

   The bundle service uses the Data.indication primitive to deliver the
   content of a bundle to one or more bundle nodes indicated by the
   bundle's destination endpoint.  One of the parameters of this
   primitive is also "delivery options".

   The Delivery Options parameter indicates the optional
   security-specific procedures to be followed when transmitting and
   delivering the application data unit.  Separate options MAY be
   specified for each of the confidentiality, authentication and error
   detection services.  In each case, we use a ciphersuite ID to
   indicate how the service is to be provided.  The ciphersuite ID can
   be omitted, leaving the decision up to the implementation.  If the
   ciphersuite ID is provided, the additional ciphersuite parameters MAY
   be provided.  The details of valid parameters are part of the
   definition of each of the ciphersuites.

   Even if the ciphersuite ID for a service is omitted, the
   implementation MAY decide to apply that service, based on some policy
   settings.  However, if a ciphersuite ID is supplied, then the
   implementation MUST NOT send the bundle without successfully applying
   the required service.

   The following service-specific parameters are defined:
      Confidentiality - indicates that a CH header MUST be applied to
      the bundle, and at least the bundle payload (and possibly other
      bundle headers) MUST be encrypted appropriately[Comment.9]
      Authentication - indicates that a PSH MUST be applied to the
      bundle, and the (relevant parts of the) bundle digitally signed or
      MACed appropriately
      Error detection - indicates that a PSH MUST be applied to the
      bundle and the (relevant parts of the) bundle digested
      appropriately [Comment.10]

   Notes:
      1) The above means that a given bundle can only use one of the
      authentication or error detection services
      2) Hop-by-hop authentication is not controlled using this
      interface

Symington, et al.       Expires November 25, 2005               [Page 8]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

      3) Throughout this specification we use the standard security
      usage of the acronym MAC - meaning "message authentication code"

2.2  Data indications

   As with Send.request, Data.indication primitives SHOULD indicate the
   security services which were applied to the message.  In each case
   the indication MUST contain a ciphersuite ID and MAY contain a
   ciphersuite-specified ciphersuite parameters item.  Note that the
   ciphersuite parameters may differ between the Send.request and
   Data.indication primitives, e.g.  for a confidentiality item in a
   Send.request, the security-destination will often be a parameter,
   whereas the security-source is what is of interest for the
   Data.indication (if the ciphersuite allows).

   We define the following indications:
      The presence of the Confidentiality item in the Data.indication
      primitive indicates that the bundle contained a CH and that its
      payload was encrypted.  Note that it is possible that this bundle
      protocol agent is not the CH security-destination, i.e.  the
      payload may have been decrypted by a bundle protocol agent earlier
      in the route.
      The presence of the Authentication Item in the Data.indication
      primitive indicates that the bundle contained a PSH with an
      authentication ciphersuite.  Note that it is possible that this
      bundle protocol agent is not the PSH security-destination, i.e.
      the PSH MAY have been verified by a bundle protocol agent earlier
      in the route.
      The presence of the Error Detection item in the Data.indication
      primitive indicates that the received bundle included a PSH with
      an error detection ciphersuite.

2.3  The At-Most-Once-Delivery Option

   The bundle service consumes a Register.request primitive that is used
   to notify the bundle protocol agent of a bundle node's interest in
   bundles destined for a specified bundle endpoint and of the action to
   take on the bundle node's behalf with regard to those bundles.  One
   of the parameters of this primitive is "at-most-once-delivery".
   [Comment.11] If this parameter is set, then the bundle node
   registering interest in receiving bundles is indicating that the
   receiving bundle protocol agent SHALL check for replayed bundles,
   discard duplicates, and deliver at most one copy of each received
   bundle to the registering bundle node.  If this parameter is not set,
   the bundle node is indicating that the receiving bundle protocol
   agent SHALL deliver all received bundle copies to the registering
   bundle node.  If this parameter is not set, the bundle protocol agent
   MAY (subject to policy) deliver all bundles or else behave as if this

Symington, et al.       Expires November 25, 2005               [Page 9]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   parameter had been set.[Comment.12]

   A method that the receiving bundle protocol agent MAY [Comment.13]
   use to detect duplicates is to look at the (source, timestamp) pair
   value of each received bundle and determine if this pair value, which
   uniquely identifies a bundle, has been received before.  If it has,
   then the bundle is a duplicate and SHALL be discarded.  If it has
   not, then the bundle SHALL be delivered to the bundle node and the
   (source, timestamp) pair value SHALL be added to the list of pair
   values already received by that bundle protocol agent.

Symington, et al.       Expires November 25, 2005              [Page 10]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

3.  Security Headers

   There are three security headers that MAY be included in a bundle as
   listed in the Bundle Protocol [2].  These are the Bundle
   Authentication Header (BAH), the Payload Security Header (PSH), and
   the Confidentiality Header (CH).
      The BAH is used to assure the authenticity of the bundle along a
      single hop from sender to recipient.
      The PSH is used to assure the authenticity of the bundle from the
      PSH security-source, which creates the PSH, to the PSH
      security-destination, which verifies the PSH authenticator.  The
      authentication information in the PSH may (if the ciphersuite
      allows) be verified by any bundle protocol agent in between the
      PSH security-source and the PSH security-destination that has
      access to the cryptographic keys and revocation status information
      required to do so.
      The CH indicates that the bundle payload (and possibly other
      bundle fields) has been encrypted while en route between the CH
      security-source and the CH security-destination.

3.1  Abstract Security Header

   Since the three security headers have most fields in common, we can
   shorten the description of them if we first define an abstract
   security header (ASH) and then specify each of the real headers in
   terms of the fields which are present/absent in an ASH.  Note that no
   bundle ever contains an ASH, which is simply a specification artifact

   An ASH consists of the following mandatory and optional fields:
   [Comment.14]
      Header-type - as in all bundle protocol headers except the primary
      bundle header
      Flags - as in all bundle protocol headers[Comment.15]
      Length - the overall length of this header encoded as an SDNV-8
      (see below).  This includes the bytes required for the header type
      and ciphersuite ID fields.
      Ciphersuite ID - identifies the ciphersuite in use.  This is one
      byte long, though the top three bytes are used to indicate the
      presence or absence of the three optional fields (see below).
      (optional) Ciphersuite parameters - parameters to be used with the
      ciphersuite in use, e.g.  a key identifier or initialization
      vector (IV).  This is encoded as an SDNV-8.
      (optional) Security-source - specifies the security source for the
      service.  If this is omitted, then the source of the bundle is
      assumed to be the security-source.  This is encoded using the
      normal bundle identity encoding scheme (see below).
      (optional) Security-destination - specifies the security
      destination for the service.  If this is omitted, then the

Symington, et al.       Expires November 25, 2005              [Page 11]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

      destination of the bundle is assumed to be the
      security-destination.  This is encoded using the normal bundle
      identity encoding scheme (see below).
      Security result - contains the results of the appropriate
      ciphersuite-specific calculation (e.g.  a signature, or MAC or
      encrypted session key).  This is encoded as an SDNV-16.

   The ciphersuite ID is an eight bit value with the top three bits
   indicating which of the optional fields are present (value =3D "1") =
or
   absent (value=3D"0").  The remaining five bits indicate the
   ciphersuite.

   Some ciphersuites are specified in Section 5, which also specifies
   the rules which MUST be satisfied by ciphersuite specifications.
   Additional ciphersuites MAY be defined in separate specifications.

   The structure of the ciphersuite ID byte is shown in Figure 2
      src - the most significant bit (bit 7) indicates whether the ASH
      contains an optional security source (value=3D"1") or not
      (value=3D"0")
      dest - the 2nd most significant bit (bit 6) indicates whether the
      ASH contains an optional security destination (value=3D"1") or not
      (value=3D"0")
      parm - the 3rd most significant bit (bit 5) indicates whether the
      ASH contains an optional ciphersuite parameters (value=3D"1") or =
not
      (value=3D"0")

   Ciphersuite ID
   Bit    Bit   Bit   Bit   Bit   Bit   Bit   Bit
    7     6     5     4     3     2     1     0
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |src  |dest |parm |      ciphersuite ID         |
   +-----+-----+-----+-----+-----+-----+-----+-----+

                                Figure 2

   The Self-Delimiting Numeric Value (SDNV) scheme is a way of encoding
   variable length values and is described in the Licklider Transmission
   Protocol [5].  There are two variants described there: SDNV-8 and
   SDNV-16 and we use both.

   The security source and destination fields are encoded as are all
   other bundle endpoint IDs using the schema/mark scheme specified in
   the base Bundle Protocol Specification.  [2]

   A little bit more terminology: when the header is a PSH then we refer
   to the PSH-source when we mean the security source field in the PSH.

Symington, et al.       Expires November 25, 2005              [Page 12]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   Similarly we may refer to the CH-dest, meaning the
   security-destination field of the CH.

3.2  Bundle Authentication Header

   A BAH is an ASH with the following additional restrictions:
      the header-type value MUST be 0x07 as defined in the Bundle
      Protocol Specification [2]
      the flags field MUST be present as defined in the Bundle Protocol
      Specification
      the ciphersuite ID MUST be documented as a hop-by-hop
      authentication-ciphersuite
      the ciphersuite parameters field MAY be present
      the security-source field MUST NOT be present[Comment.16]
      the security-destination field MUST NOT be present
      the security result is effectively the "output" from the
      ciphersuite calculation (e.g.  the MAC or signature) applied to
      the (relevant parts of) the bundle.

3.3  Payload Security Header

   A PSH is an ASH with the following additional restrictions:
      the header-type value MUST be 0x08 as defined in the Bundle
      Protocol Specification [2]
      the flags field MUST be present as defined in the Bundle Protocol
      Specification.  It SHOULD indicate that the header does not need
      to be duplicated on all fragments.
      the ciphersuite ID MUST be documented as an end-to-end
      authentication-ciphersuite or as an end-to-end
      error-detection-ciphersuite; the type of protection provided by
      the PSH (authentication versus error-detection) is indicated by
      the type of ciphersuite used
      the ciphersuite parameters field MAY be present
      the security-source field MAY be present
      the security-destination field MAY be present
      the security result is effectively the "output" from the
      ciphersuite calculation (e.g.  the MAC or signature) applied to
      the (relevant parts of) the bundle.

   For some ciphersuites, (e.g.  those using asymmetric keying to
   produce signatures or those using symmetric keying with a group key),
   the security information can be checked at any hop on the way to the
   destination that has access to the required keying information.

   Most symmetric PSH-ciphersuites will not require a PSH-source but
   simply a PSH-destination to indicate which node has access to the key
   needed to verify the PSH authenticator.  Most asymmetric
   PSH-ciphersuites will use the PSH-source to indicate the signer and

Symington, et al.       Expires November 25, 2005              [Page 13]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   will not require the PSH-dest field because the key needed to verify
   the PSH authenticator will be a public key associated with the
   PSH-source.

3.4  Confidentiality Header
   [Comment.17]

   A PSH is an ASH with the following additional restrictions:
      the header-type value MUST be 0xTBD [Comment.18]
      the flags field MUST be present as defined in the Bundle Protocol
      Specification.  It SHOULD indicate that the header does not need
      to be duplicated on all fragments.
      the ciphersuite ID MUST be documented as a
      confidentiality-ciphersuite
      the ciphersuite parameters field MAY be present
      the security-source field MAY be present
      the security-destination field MAY be present
      the security result normally represents an encrypted bundle
      encryption key

   A typical confidentiality ciphersuite will encrypt the payload using
   a randomly generated payload encrypting key (PEK) and then use the
   security result to carry the PEK encrypted with some long term key
   encryption key (KEK).  The CH-dest field will typically indicate the
   decryption key with which the PEK can be recovered.[Comment.19]

 3.5   PSH and CH combinations
   [Comment.20]

Symington, et al.       Expires November 25, 2005              [Page 14]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

 4.   Security Processing

   This section describes the security aspects of bundle processing.
   The subsections here parallel the subsections of section 4, Bundle
   Processing, in the Bundle Protocol Specification [2] to make it
   easier for the reader to understand how the security steps described
   herein fit into the Bundle Protocol.  [Comment.21]

   All Bundle Protocol Agents are required to have and enforce their own
   configurable security policies, whether these policies be explicit or
   default, as defined in Section 6.

4.1  Bundle Transmission Requests

   As described in Section 4.1 of the Bundle protocol [2], which
   enumerates the steps in processing a Send.request primitive, all
   bundle protocol agents serve as Policy Enforcement Points (PEP)
   insofar as they enforce polices that may restrict the permissions of
   bundle nodes to inject traffic into the network.  If a particular
   Send.request satisfies the bundle protocol agent's policy and is
   therefore accepted, then an outbound bundle SHALL be created and
   dispatched.  The security-specific steps in processing a Send.request
   primitive to create the outbound bundle are as follows:

   For clarity, the text below ignores the fact that the policy
   enforcing code MAY override all of the processing steps described.
   For example, it is valid to implement a bundle protocol agent which
   always attempts to attach a PSH.  Similarly it is also valid to
   implement a bundle protocol agent which always rejects all requests
   which imply the use of a PSH.  Basically, the policy code is allowed
   to override the algorithm described below, except in the case in
   which the Send.request asks for some service that is not allowed by
   the policy code.  In this case, the bundle protocol agent MUST NOT
   send a bundle because to do so by sending a bundle without the
   requested service would mean that the bundle protocol agent would be
   transmitting data in a manner that is not as secure as was requested,
   but without the bundle node's knowledge.

   If the Send.request primitive includes a Delivery Options parameter
   and that Delivery Options parameter includes a Payload Security
   Requirements item, the following steps SHALL be taken, in order,
   depending on the values of the Confidentiality, Authentication, and
   Error-detection elements of the Payload Security Requirements item.
   If the Send.request primitive does not include a Delivery Options
   parameter with a Payload Security Requirements item, processing SHALL
   proceed beginning at Section 4.5 below.
      Confidentiality

Symington, et al.       Expires November 25, 2005              [Page 15]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

         If the Confidentiality element is present in the Delivery
         Options parameter of the Send.request primitive, this indicates
         that the payload MUST be encrypted and a CH header MUST be
         added to the bundle.
         If the Confidentiality element is not present, a CH header
         SHALL NOT be created for this bundle, unless indicated by local
         policy.
      Authentication
         If the authentication element is present in the Delivery
         Options parameter of the Send.request primitive a PSH SHALL be
         created.  (If both the authentication and error-detection
         options are indicated in the Send.request primitive, the
         authentication option takes precedence and authentication is
         provided, because authentication encompasses both
         authentication and error-detection.)
      Error-detection
         If the Error-detection element is present in the Delivery
         Options parameter of the Send.request primitive but the
         Authentication element is not present, a PSH SHALL be created.
         If neither the Authentication nor the Error-detection elements
         of the Delivery Options parameter of the Send.request primitive
         are present, a Payload Security Header SHALL NOT be created for
         this bundle, unless indicated by local policy.
      Ciphersuites and Ciphersuite Parameters
      The following rules hold for each of the confidentiality,
      authentication, and error-detection elements:
         If any element (confidentiality, authentication, or
         error-detection) includes a ciphersuite ID then the
         corresponding header (CH or PSH) and calculation MUST use this
         ciphersuite or else the bundle MUST NOT be
         transmitted/forwarded.  All rules specified in the ciphersuite
         definition MUST be followed.
         If any element does not include a ciphersuite ID then the
         corresponding header and calculation MUST use the default
         ciphersuite or else the bundle MUST NOT be
         transmitted/forwarded.  All rules specified in the default
         ciphersuite definition MUST be followed.
         If ciphersuite parameters are provided they MUST be honored.
         It is an error to emit a bundle using some other parameters.
         If ciphersuite parameters are not provided then the default
         parameters for that ciphersuite MUST be used.

4.2  Canonicalisation of bundles

   In order to verify a signature or MAC on a bundle the exact same bits
   must be input to the calculation upon verification as were input upon
   initial computation of the original signature or MAC value.  Since
   bundles may be modified while in transit (either correctly or due to

Symington, et al.       Expires November 25, 2005              [Page 16]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   implementation errors), a canonical form of any given bundle (that
   contains a PSH) must be defined.

   This section defines the default bundle canonicalisation
   algorithm.[Comment.22]

   In order for the PSH to be useful, all bundle information over which
   the PSH is calculated at the source must be the same, and in the same
   order, as all bundle information over which the PSH is calculated at
   the point at which the PSH is being validated.  Therefore, the
   following transmission requirements SHALL hold:

   Once any of the following headers are placed in a bundle, they MUST
   both remain in the bundle and continue to be positioned in the same
   order relative to one another in the bundle as the bundle travels
   through the DTN to its destination.  Neither the presence nor the
   position of these headers relative to one another is allowed to
   change at any time.  If the bundle becomes fragmented, each of these
   headers MUST be present in some fragment and they must continue to be
   positioned in the same order following bundle re-assembly:

      Primary Bundle Header
      Dictionary Header
      Override Report-to Header
      Source Routing Header
      Payload Security Header
      Confidentiality Header
      Bundle Payload Header

   If a Payload Security Header is placed in a bundle, it MUST remain in
   the bundle and continue to be positioned in the same order relative
   to the other bundle headers as the bundle travels throughout the DTN.
   However, if the bundle becomes fragmented, at least the fragment
   containing the initial portion of the original payload (that is, the
   fragment that has a Fragment Offset field value of zero) MUST contain
   the PSH and at least some fragment MUST contain the CH.

   The following additional headers MAY be present in the bundle when it
   arrives at a bundle protocol agent or at the destination, and if they
   are present, they must be (logically) removed from the bundle before
   the PSH is verified:

      Custody related headers
      Bundle Authentication Header
      Bundle Fragment Header

   Before the PSH is initially calculated and before it is verified by
   applying the appropriate ciphersuite to the appropriate parts of the

Symington, et al.       Expires November 25, 2005              [Page 17]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   bundle, the fields of the bundle that are mutable as the bundle
   travels from source to destination must be temporarily made
   irrelevant to the calculation by performing the following:
      the BAH, if present, MUST be removed from the bundle
      the offset values in the source, destination, reply-to endpoint,
      sender, CH security-source (if present), CH security-destination
      (if present), PSH security-source (if present), and PSH
      security-destination (if present) fields must be used to obtain
      the corresponding scheme/mark format of the endpoint IDs from the
      dictionary header and these endpoint IDs MUST be substituted for
      their corresponding fields in the concatenated bundle header for
      purposes of calculating the PSH authenticator over the bundle.
      Note that if additional bundle headers that contain offsets into
      the dictionary header are defined (e.g., a source route header),
      then the definition of the new header SHOULD specify whether or
      not the referenced endpoint IDs should be substituted for the
      corresponding offset fields in the new header when constructing
      the canonical form of the bundle for purposes of computing the
      PSH.  If a new header is defined and its definition does not
      specify whether or not the referenced endpoint IDs should be
      substituted for the corresponding fields in the header, then by
      default they SHALL be.
      the portion of the dictionary header corresponding to the
      custodian field (as indicated by the offset value in the custodian
      field of the Primary Bundle Header) MUST be zeroed out
      the portion of the dictionary header corresponding to the sender
      field (as indicated by the offset value in the sender field of the
      Primary Bundle Header) MUST be zeroed out
      the security information field of the PSH MUST be zeroed
      out[Comment.23]

4.3  Creating a Confidentiality Header

   This subsection describes the steps taken to create the CH and
   populate it with the appropriate values as well as modify the payload
   field of the Bundle Payload Header.

   If the CH is being created by some entity other than the bundle
   source, then a CH-source field MUST be placed in the CH and populated
   with the endpoint ID of the entity creating the CH.  [Comment.24]

   The values of the CH MUST be populated as described in Section 3 and
   according to the rules of the relevant ciphersuite described in
   Section 5.  All ciphersuites will require the input to the security
   result calculation to include at least the bundle payload.  Some
   ciphersuites will require the input to include the bundle payload
   concatenated with some canonical sequence of bundle header fields
   (e.g., source, destination, portions of the dictionary header) for

Symington, et al.       Expires November 25, 2005              [Page 18]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   which confidentiality will also be provided.  Note that the security
   result calculated will be placed in the payload field of the bundle
   payload header.  The CH does not include a field for the security
   result.[Comment.25]

 4.4   Creating the Payload Security Header

   This subsection describes the steps taken to create the PSH and
   populate it with the appropriate values.

   A PSH MUST be created after all other bundle headers except for the
   BAH have been added to the bundle and populated with their correct
   values.

   If the PSH is being created by some entity other than the bundle
   source, then a PSH-source field MUST be placed in the PSH and
   populated with the endpoint ID of the entity creating the PSH.

   The values of the PSH MUST be populated as described in Section 3 and
   according to the rules of the relevant ciphersuite described in
   Section 5.  Almost all ciphersuites will require the input to the
   security result calculation to be the canonical form (see
   Section 4.2) of the bundle.

4.5  Creating the Bundle Authentication Header

   Regardless of whether or not the Send.request primitive includes a
   delivery options parameter, the bundle protocol agent SHALL consult
   its security policy to determine whether or not the bundle MUST be
   provided with a Bundle Authentication Header before being forwarded.
   If the bundle does not need to be provided with a BAH, no additional
   security-related processing is required.

   The optional ciphersuite parameters field of the BAH SHOULD (if
   bandwidth permits) be included in the BAH.

   The authentication information field of the PSH SHALL be zeroed out
   before the ciphersuite is applied to the (relevant parts of) the
   bundle.

4.6  Bundles received from other bundle protocol agents

   The security-specific steps in processing a bundle received from
   another bundle protocol agent are as follows:

   The receiving bundle protocol agent SHALL consult its security policy
   to determine whether or not the bundle is required to include a BAH.
   If the bundle is not required to have a BAH, then security processing

Symington, et al.       Expires November 25, 2005              [Page 19]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   on the received bundle is complete and the bundle is ready to be
   processed for either local delivery or forwarding.

   If the bundle is required to have a BAH but it does not, then the
   bundle MUST be discarded and processed no further; in this case a
   bundle status report indicating the authentication failure MAY be
   generated, destined for the receiving bundle protocol agent's own
   endpoint.

   Otherwise, if the bundle does have a BAH, then the value in the
   authentication information field of the BAH of the received bundle
   MUST be verified according to the ciphersuite specification.  If the
   check fails, the bundle has failed to authenticate and the bundle
   SHALL be discarded and processed no further; in this case, a bundle
   status report indicating the authentication failure MAY be generated,
   destined for the receiving bundle protocol agent's own endpoint.
   Otherwise, if the BAH verifies, it is ready to be processed for
   either local delivery or forwarding.

4.7  Local Bundle Delivery

   The security-specific steps in processing a bundle if one or more
   bundle nodes have registered with the bundle protocol agent to
   receive bundles sent to the bundle's destination endpoint ID are as
   follows:

   These steps SHALL be performed after the payload of the original
   bundle has been reassembled from the payloads of received fragments,
   if necessary, to reconstruct the original bundle in its entirety.

   If the bundle does not include a Payload Security Header, then
   security processing on the received bundle should proceed from
   Section 4.8 below.  Otherwise, if the bundle does include a PSH, then
   the value in the security results field of the PSH of the received
   bundle MUST be verified according to the rules of the ciphersuite.

   If the received value fails verification, the bundle has failed to
   authenticate and the bundle SHALL be discarded and processed no
   further; in this case, a bundle status report indicating the
   authentication failure MAY be generated, destined for the receiving
   bundle protocol agent's own endpoint.  Otherwise, if the check
   passes, the bundle has been authenticated as having been sent from
   the claimed source and as not having been modified since being sent.

4.8  Optionally checking for Replays

   If one or more bundle nodes have indicated that they want to use the
   "at most once" delivery option when they registered with the bundle

Symington, et al.       Expires November 25, 2005              [Page 20]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   protocol agent using the destination endpoint ID that is in the
   bundle, then the bundle protocol agent MUST compare the (source,
   timestamp) pair values of the bundle with the local list of such
   values of already-received bundles.  If the pair value is a
   duplicate, the bundle MUST be discarded and a bundle status report
   indicating the failure MAY be generated, destined for the receiving
   bundle protocol agent's own endpoint.  If the pair value is unique,
   the pair MUST be added to the local list.

4.9  Bundle Forwarding

   The security-specific steps in processing a bundle if no bundle nodes
   have registered with the bundle protocol agent to receive bundles
   sent to the bundle's destination endpoint ID are as follows:

   The bundle protocol agent SHALL determine the next hop for the
   bundle.

   The bundle protocol agent SHALL consult its security policy to
   determine the criteria that the received bundle ought to meet before
   it will be forwarded.  These criteria MAY include a determination of
   whether or not the received bundle must include a valid BAH, PSH or
   CH.  If the bundle does not meet the bundle protocol agent's policy
   criteria, then the bundle MUST be discarded and processed no further;
   in this case, a bundle status report indicating the failure MAY be
   generated, destined for the forwarding bundle protocol agent's own
   endpoint.  [Comment.26][Comment.27]

   If the bundle does meet the bundle protocol agent's policy criteria,
   then the bundle protocol agent's endpoint ID SHALL be inserted into
   the Data Dictionary, if it is not already there, and a pointer to
   this string SHALL be placed in the sender ID field of the Primary
   Bundle Header.

   If the bundle is not a bundle fragment, and if the bundle does not
   already have a PSH, the bundle protocol agent SHALL consult its
   security policy to determine whether or not it should add a PSH to
   the bundle.  If so, the PSH SHALL be created and have its fields
   populated with all of the appropriate values as described in
   "Creating the Payload Security Header" (see Section 4.4).  In
   particular, the forwarding bundle protocol agent MUST populate the
   Security Source field of the PSH with its own endpoint ID.

   Next, the bundle protocol agent SHALL consult its security policy to
   determine whether or not the bundle needs to be given a BAH.  If so,
   the BAH SHALL be created and have its fields populated with all of
   the appropriate values as described in "Creating the Bundle
   Authentication Header" (Section 4.5).

Symington, et al.       Expires November 25, 2005              [Page 21]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   If the bundle is to be fragmented before being forwarded, each of the
   fragments MUST be given its own BAH that is specific to that
   fragment.

   At this point, the bundle is ready for forwarding.

4.10  Bundle Fragmentation and Reassembly

   If it is necessary for a bundle protocol agent to fragment a bundle
   and security is being used on that bundle, the following
   security-specific processing is REQUIRED:

   If the bundle is required by the security policy to have a BAH before
   being forwarded, all fragments resulting from that bundle MUST
   contain individual BAH values.

   If the original bundle had a PSH, then the fragment that is given a
   Fragment Offset field value of zero MUST include an exact copy of the
   PSH that was in the original bundle.

   If the original bundle had a CH, then some fragment MUST include an
   exact copy of the CH that was in the original bundle.

   When original bundle transmission is terminated before the entire
   payload has been transmitted, the receiving bundle protocol agent
   SHALL consult its security policy to determine whether it is
   permitted to transform the received portion of the bundle into a
   bundle fragment for further forwarding.  Whether or not such reactive
   fragmentation is permitted SHALL be dependent on the security policy
   in combination with the ciphersuite used to calculate the BAH
   authentication information.  [Comment.28]

   In such cases, if the original bundle is fragmented by the recipient
   (reactively), and the BAH-ciphersuite is a TP-ciphersuite (see
   Section 5), the bundle MUST be fragmented immediately after the last
   hash value in the partial payload that is received.  Any data
   received after the last hash value MUST be dropped.

   If an original bundle transmission is terminated before the entire
   payload has been transmitted, if the truncated bundle arriving at the
   receiving bundle protocol agent is reactively fragmented and
   forwarded, only the part of the bundle that was not received must be
   retransmitted at the source (providing it has not yet expired).
   Before retransmitting this portion of the bundle, it SHALL be changed
   into a fragment and, if the original bundle included a BAH, the
   fragmented bundle MUST also, and its BAH SHALL be recalculated.  If a
   TP-type ciphersuite is in use for this bundle, all of the hashes
   interspersed in its payload shall be recalculated.

Symington, et al.       Expires November 25, 2005              [Page 22]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

4.11  Custodial Retransmission and Release

   No security-specific steps relating to the custodial retransmission
   and release phase of bundle processing have yet been identified.

4.12  Bundle Status Report Status Flags

   The following security-specific values for Bundle Status Report
   Status Flags have been defined in addition to those already present
   in Table 5 of the Bundle Protocol Specification [2]:
      A source was found to lack the appropriate permissions to use the
      requested COS
      The security policy does not permit acceptance of a bundle is
      received without a BAH.
      A bundle failed the hop-by-hop bundle authentication check (using
      the Bundle Authentication Header).
      A bundle failed the end-to-end authentication check (using the
      Payload Security Header) at an intermediate DTN security policy
      node.
      A bundle was found to be an illegitimate replay at an intermediate
      node.  (Note that no method of detecting such replays has yet been
      defined.)
      A bundle failed the end-to-end authentication check (using the
      Payload Security Header) at the destination host.
      A bundle was found to be an illegitimate replay at the destination
      host.
      Received a payload longer than that defined by the preceding
      bundle header.
      The indicated BAH ciphersuite is not implemented.
      The indicated PSH ciphersuite is not implemented.
      the indicated CH ciphersuite is not implemented.

4.13  Convergence Layer Security Services

   As discussed in the Bundle Protocol Specification [2], the
   convergence layer SHALL deliver the Bundle.indication primitive to
   the bundle protocol, and one of the parameters of this primitive,
   Bundle Authenticity, is security-specific.  The meaning of this
   parameter and its possible values are defined in the Bundle Protocol
   Specification [2].

Symington, et al.       Expires November 25, 2005              [Page 23]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

5.  Ciphersuites

   Four types of ciphersuites are defined:
      hop-by-hop authentication ciphersuites for use in the BAH
      end-to-end authentication ciphersuites for use in the PSH
      end-to-end error-detection ciphersuites for use in the PSH
      confidentiality ciphersuites

   The ciphersuite field of the BAH, PSH and CH are 5-bit integer values
   as defined below: [Comment.29]
      EntireBundleHMAC - value 000
      HeadOfBundleHMAC - value 001
      EntireBundleSig - value  011
      HeadOfBundleSig - value  010
      CombinationSig - value   100
      EntireBundleMAC - value  101
      TP-HMAC - value 1111
      TP-HSIG - value 1110
      TP-DSS  - value 1101[Comment.30]

5.1  EntireBundleHMAC Ciphersuite

   This ciphersuite involves computing a MAC over the entire bundle
   using HMAC-SHA1.  It is both a hop-by-hop authentication ciphersuite
   and an end-to-end authentication ciphersuite, so it may be used to
   calculate the BAH security result and/or the PSH security result.

   If used to calculate the BAH security result, the authentication
   information field of the BAH MUST be zeroed out before the
   ciphersuite is applied, and the ciphersuite MUST be applied to the
   entire bundle.

   If used to calculate the PSH security result, the bundle must be put
   into canonical form as described in Section 4.2 before the
   ciphersuite is applied, and the ciphersuite MUST be applied to the
   entire bundle.

5.1.1  Ciphersuite Parameters

   This ciphersuite has one associated parameter, which identifies the
   cryptographic key used in the HMAC computation.  This parameter is
   encoded in SDNV-8 format.

5.2  HeadOfBundleHMAC Ciphersuite

   This ciphersuite involves computing a MAC over the entire bundle
   except for the payload field of the Bundle Payload Header using
   HMAC-SHA1.  It is both a hop-by-hop authentication ciphersuite and an

Symington, et al.       Expires November 25, 2005              [Page 24]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   end-to-end authentication ciphersuite, so it may be used to calculate
   the BAH security result and/or the PSH security result.

   If used to calculate the BAH security result, the authentication
   information field of the BAH MUST be zeroed out before the
   ciphersuite is applied, and the ciphersuite MUST be applied to the
   entire bundle except for the payload field.

   If used to calculate the PSH security result, the bundle must be put
   into canonical form as described in Section 4.2 before the
   ciphersuite is applied, and the ciphersuite MUST be applied to the
   entire bundle except for the payload field.

5.2.1  Ciphersuite Parameters

   This ciphersuite has one associated parameter, which identifies the
   cryptographic key used in the HMAC computation.  This parameter is
   encoded in SDNV-8 format.

5.3  EntireBundleSig Ciphersuite

   This ciphersuite involves using SHA-1 to compute a hash over the
   entire bundle and then signing this hash by generating a Digital
   Signature Standard (DSS) signature.  It is both a hop-by-hop
   authentication ciphersuite and an end-to-end authentication
   ciphersuite, so it may be used to calculate the BAH security result
   and/or the PSH security result.

   If used to calculate the BAH security result, the authentication
   information field of the BAH MUST be zeroed out before the
   ciphersuite is applied, and the ciphersuite MUST be applied to the
   entire bundle.

   If used to calculate the PSH security result, the bundle must be put
   into canonical form as described in Section 4.2 before the
   ciphersuite is applied, and the ciphersuite MUST be applied to the
   entire bundle.

5.3.1  Ciphersuite Parameters

   This ciphersuite has one associated parameter, which identifies the
   cryptographic key used to create the signature.  This parameter is
   encoded in SDNV-8 format.

5.4  HeadOfBundleSig Ciphersuite

   This ciphersuite involves using SHA-1 to compute a hash over the
   entire bundle except for the payload field of the Bundle Payload

Symington, et al.       Expires November 25, 2005              [Page 25]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   Header and then signing this hash by generating a DSS signature.  It
   is both a hop-by-hop authentication ciphersuite and an end-to-end
   authentication ciphersuite, so it may be used to calculate the BAH
   security result and/or the PSH security result.

   If used to calculate the BAH security result, the authentication
   information field of the BAH MUST be zeroed out before the
   ciphersuite is applied, and the ciphersuite MUST be applied to the
   entire bundle except for the payload field.

   If used to calculate the PSH security result, the bundle must be put
   into canonical form as described in Section 4.2 before the
   ciphersuite is applied, and the ciphersuite MUST be applied to the
   entire bundle except for the payload field.

5.4.1  Ciphersuite Parameters

   This ciphersuite has one associated parameter, which identifies the
   cryptographic key used to create the signature.  This parameter is
   encoded in SDNV-8 format.

5.5  CombinationSig Ciphersuite
   [Comment.31]

   This ciphersuite involves using SHA-1 to compute two hash values: a
   hash over just the head of the bundle (the entire bundle except for
   the payload field of the Bundle Payload Header), and a hash over the
   entire bundle.  These two hash values are concatenated (the hash of
   the head of the bundle preceding the hash of the entire bundle) and
   the concatenated result is signed by generating a DSS signature.  It
   is only a hop-by-hop authentication ciphersuite, so it may only be
   used to calculate the BAH security result.

   The authentication information field of the BAH MUST be zeroed out
   before this ciphersuite is applied.

5.5.1  Ciphersuite Parameters

   This ciphersuite has one associated parameter, which identifies the
   cryptographic key used to create the signature.  This parameter is
   encoded in SDNV-8 format.

5.6  EntireBundleMAC

   This ciphersuite involves using SHA-1 to compute a hash value over
   the entire bundle.  No keys are involved.  It is only an end-to-end
   error-detection ciphersuite, so it may only be used to calculate the
   PSH security result.

Symington, et al.       Expires November 25, 2005              [Page 26]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   The bundle must be put into canonical form as described in
   Section 4.2 before this ciphersuite is applied, and the ciphersuite
   MUST be applied to the entire bundle.

5.6.1  Ciphersuite Parameters

   This ciphersuite has no associated parameters, so no associated
   parameters fields are included in the PSH when this ciphersuite is
   used.

5.7  TP-type Ciphersuites
   [Comment.32]

   All TP-type ciphersuites involve breaking the bundle payload into
   segments of a given size, computing authentication information for
   the bundle header concatenated with that payload segment, and
   inserting the authentication information for a given segment into the
   payload itself right after the given segment.  Therefore, the payload
   of a bundle on which the TP Ciphersuite was used to calculate the
   authentication information would be formatted as a sequence of
   payload segments of a given size interspersed with authentication
   information of a given size.  [Comment.33]

   There are several TP-type ciphersuites that have been defined.  All
   involve formatting the payload as fixed-length segments of payload
   followed by fixed-length authentication information calculated over
   the bundle header concatenated with the previous payload segment.
   The only differences between the various TP-type ciphersuites is the
   method used to calculate the authentication information.
   [Comment.34]

   We may define the following TP-ciphersuites:
      TP-HMAC Ciphersuites
      TP-HSIG Ciphersuites
      TP-DSS Ciphersuites
   [Comment.35]

 5.7.1   Ciphersuite Parameters

   The following two parameters must be included with TP-type
   ciphersuites that use fixed-length payload and segment sizes:
   segment-length, authenticator-length.  These two fields MUST be
   included in the BAH and PSH headers that use such TP-type
   ciphersuites and they MUST be encoded in SDNV-8 format.

Symington, et al.       Expires November 25, 2005              [Page 27]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

6.  Default Values

   Several of the security headers include optional fields that MAY
   contain ciphersuite parameter information.  If a bundle includes a
   security header that does not contain one of these optional fields,
   then the default value for that field SHALL be used.  The default
   values are as follows:

   BAH Ciphersuite ID: EntireBundleSig [Comment.36]

   BAH EntireBundleSig parameters: The key associated with the endpoint
   indicated in the sender field of the Primary Bundle Header.  If this
   value is not valid, use the key associated with the endpoint ID that
   was passed up as a parameter of the Bundle.Indication primitive.

   PSH Ciphersuite ID when Authentication is being used: TBD

   PSH Ciphersuite ID when Error Detection is being used: TBD

   PSH ciphersuite parameters: If the PSH includes an optional PSH
   Security-Source field, use the key associated with the endpoint
   indicated in this field.  Otherwise, use the key associated with the
   endpoint indicated by the source field of the primary bundle header.

   CH ciphersuite ID: TBD

   CH ciphersuite parameter: If the CH includes an optional CH
   Security-Source field, use the key associated with the endpoint
   indicated in this field.  Otherwise, use the key associated with the
   endpoint indicated by the source field of the primary bundle header.

   Default Security Policy.  Every bundle protocol agent serves as a
   Policy Enforcement Point (PEP) insofar as it enforces some policy
   that controls the forwarding and delivery of bundles via one or more
   interfaces.  Consequently, every bundle protocol agent SHALL have and
   operate according to its own configurable security policy, whether
   the policy be explicit or default.  The policy SHALL specify:
      Under what conditions received bundles SHALL be forwarded.
      Under what conditions received bundles SHALL be required to
      include valid BAHs.
      Under what conditions the authentication information provided in a
      bundle's BAH SHALL be deemed adequate to authenticate the bundle.
      Under what conditions received bundles SHALL be required to have
      valid PSHs.
      Under what conditions the authentication information provided in a
      bundle's PSH SHALL be deemed adequate to authenticate the bundle.
      Under what conditions a BAH SHALL be added to a received bundle
      before that bundle is forwarded.

Symington, et al.       Expires November 25, 2005              [Page 28]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

      Under what conditions a PSH SHALL be added to a received bundle
      before that bundle is forwarded.
      The actions that SHALL be taken in the event that a received
      bundle does not meet the receiving bundle protocol agent's
      security policy criteria.

   This specification does not address how security policies get
   distributed to bundle protocol agents.  It only REQUIRES that bundle
   protocol agents have and enforce security policies.  [Comment.37]

   If no security policy is specified at a given bundle protocol agent,
   or if a security policy is only partially specified, that bundle
   protocol agent's default policy regarding unspecified criteria SHALL
   consist of the following:
      Bundles that are not well-formed do not meet the security policy
      criteria.
      All bundles received MUST either have their authenticity asserted
      by the convergence layer or by valid authentication information
      present in a BAH.  If the value of the Bundle Authenticity
      parameter of the convergence layer Bundle.indication primitive is
      "Bundle authenticity is asserted", then bundle authentication is
      complete.  If the value of the Bundle Authenticity parameter is
      "Bundle authenticity is denied", or "Bundle authenticity is
      unknown", then the bundle MUST have a BAH and the value of the
      authentication information field of the BAH must be verified.  In
      this case, if the bundle does not have a BAH, then the bundle must
      be discarded and processed no further; a bundle status report
      indicating the authentication failure may be generated, destined
      for the receiving bundle protocol agent's own endpoint.  If the
      bundle does have a BAH, then the value in its authentication
      information field SHALL be verified.
      The authentication information value in the BAH MUST be calculated
      using the YADA-YADA-YADA ciphersuite; that is, the value MUST be
      calculated over the entire/head/specific segmented portion of the
      bundle, using the yada-yada-yada algorithms.
      No received bundles SHALL be required to have a PSH; if a received
      bundle does have a PSH, however, that can be ignored unless the
      receiving protocol agent is the destination bundle protocol agent,
      in which case the PSH MUST be verified.
      The security information value in the PSH MUST be calculated using
      the YADA-YADA-YADA ciphersuite; that is, the value MUST be
      calculated over the entire/head of the bundle, using the
      yada-yada-yada algorithms.
      A PSH SHALL NOT be added to a bundle before sourcing or forwarding
      it.
      A BAH MUST always be added to a bundle before that bundle is
      forwarded.

Symington, et al.       Expires November 25, 2005              [Page 29]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

      If a received bundle does not satisfy the bundle protocol agent's
      security policy for any reason, then the bundle MUST be discarded
      and processed no further; in this case, a bundle status report
      indicating the failure SHOULD be generated, destined for the
      receiving bundle protocol agent's own endpoint.

Symington, et al.       Expires November 25, 2005              [Page 30]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

7.  Security Considerations

   TBD.  We have to add text here describing the downside of using these
   mechanisms (e.g.  new DoS opportunities), issues with key mgmt,
   implementation hints, ciphersuite strength considerations etc.  etc.
   Ok to do it a bit later though, but we should start collecting items
   now.

8.  References

   [1]  Bradner, S. and J. Reynolds, "Key words for use in RFCs to
        Indicate Requirement Levels", RFC 2119, October 1997.

   [2]  Scott, K., "Bundle Protocol Specification",
        draft-irtf-dtnrg-bundle-spec-02.txt , September 2004.

   [3]  Symington, S., "Delay-Tolerant Network Security Overview and
        Motivation", draft-irtf-dtnrg-securityOverview-spec-01.txt ,
        March 2005.

   [4]  Cerf, V., "Delay-Tolerant Network Architecture",
        draft-irtf-dtnrg-arch-02.txt , July 2004,
        <draft-irtf-dtnrg-arch-02.txt>.

   [5]  Burleigh, S., "Licklider Transmission Protocol",
        draft-irtf-dtnrg-ltp-01.txt , July 2004.

   [6]  Durst, R., "An Infrastructure Security Model for Delay Tolerant
        Networks", http://www.dtnrg.org/ , July 2002.

   [7]  Warthman, F., "Delay-Tolerant Networks (DTNs) A Tutorial",
        http://www.dtnrg.org/ , March 2003.

Symington, et al.       Expires November 25, 2005              [Page 31]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

Editorial Comments

   [Comment.1]   Editors: Actually, the "bundle security is RECOMMENDED"
                 statement needs to be in the core Bundle Protocol spec
                 and not here. But for now, let's put it here until we
                 get agreement with the larger group.

   [Comment.2]   Editors: We're using the xml2rfc tools so embedded
                 comments are marked like this.

   [Comment.3]   Editors: This is the first informative reference. We
                 should, if we want to look like a standards-track RFC,
                 distinguish between normative and informative but I'm
                 not sure how to with this tool yet.

   [Comment.4]   Editors: There may be some (valid) question marks over
                 this terminology. We weren't entirely sure ourselves.

   [Comment.5]   Editors: There is still work to be done on how to
                 handle potential combinations of security services
                 (e.g., confidentiality with authenticity).

   [Comment.6]   Editors: We discussed whether to model e.g. the
                 "signer" as the bundle node or the bundle protocol
                 agent that provides the bundle service to the bundle
                 node. In the end, we didn't care too much and are happy
                 to allow either term. The main reasons we didn't care
                 were a) due to the fact that there's mainly no real
                 security difference since a suitable API that properly
                 isolates which layer is trusting which other layer for
                 what is at least very hard, and b) the destination
                 mostly doesn't care which layer of the cake signed in
                 any case.

   [Comment.7]   Editors: This section needs to be coordinated with the
                 Bundle Protocol Spec.

   [Comment.8]   Editors: The extent to which the interfaces defined in
                 this section should reflect a 1:1 correspondence with
                 the protocol data units is to be determined. The issue
                 is that we want to allow policy code below the
                 interface to influence matters, so, e.g. if the
                 interface omits to specify, or defaults, an algorithm
                 parameter then the implementation could select
                 anything, presumably after running some policy code.
                 The net effect is that the PDUs  reflect some
                 combination of the interface inputs and the policy
                 settings.

Symington, et al.       Expires November 25, 2005              [Page 32]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   [Comment.9]   Editors: Basic confidentiality requires that the
                 payload be encrypted; we may also want to define a
                 confidentiality service that also keeps certain fields
                 like source and destination confidential. It is not
                 clear if we should define specific ciphersuites to
                 provide specific types of confidentiality or if we
                 should specify that a tunnel be created and used to
                 provide confidentiality of the entire bundle. Note that
                 encrypting certain fields like source and destination
                 would not be sufficient, given that these fields only
                 contain offsets into the Dictionary Header. Appropriate
                 portions of the dictionary header would have to be
                 encrypted as well.

   [Comment.10]  Editors: This might be done this way or else changed to
                 not use the PSH in order to make it clearer that we're
                 not getting data integrity from this service (alone).
                 The reason to do it this way is that it provides a nice
                 debugging option to verify much of the non-key
                 management code in a bundle-security stack. That may,
                 or may not be considered sufficient benefit for the
                 potential confusion caused.

   [Comment.11]  Editors: Note, this parameter still has to be added to
                 the Bundle Spec.

   [Comment.12]  Editors: there's definitely more to be said about
                 replay, so consider this as a placeholder until
                 decisions on replay get made.

   [Comment.13]  Editors: This can't be a MAY. There has to be some MUST
                 somewhere.

   [Comment.14]  Editors: Details of this encoding scheme will change.
                 The next-header mightn't become header-type; depending
                 on how the sources are encoded (a moving target
                 elsewhere) we may need to include an offset to point to
                 the start of those and 32 is really a factor of ~3 too
                 small for specifying all standard ciphersuites ever.

   [Comment.15]  This flags field is brand new; we still  have to
                 discuss how the sittings of its various bits get
                 selected (Send.Request interface parameters, possibly
                 overridden by security policy) as well as how it is
                 treated. Security policy will take precedence. Will the
                 flags be obeyed if the policy is silent?

   [Comment.16]  Editors: This is assuming that the primary bundle

Symington, et al.       Expires November 25, 2005              [Page 33]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

                 header has a "sender" field, as has been discussed. If
                 not, the security source field MUST be present.
                 Requires coordination with the Bundle Protocol Spec.

   [Comment.17]  Editors: Note that we are defining a new
                 Confidentiality Header and its type  has to be added to
                 Table 1 of the Bundle Protocol.

   [Comment.18]  Editors: Note that we are defining a new
                 Confidentiality Header and its type  has to be added to
                 Table 1 of the Bundle Protocol.

   [Comment.19]  Howie: It may be nice to be able to signal both
                 confidentiality and authentication using only one
                 header instead of using two separate headers (PSH and
                 CH).

   [Comment.20]  Editors: As you can see - this is TBD!

   [Comment.21]  Editors: Not sure if paralleling the bundle spec. will
                 be a good or bad idea - it might be simpler to just do
                 our own thing here. I guess we'll see.

   [Comment.22]  Editors: ...but is still mainly tbd

   [Comment.23]  Editors: These instruction for canonicalisation may not
                 be exactly correct, but we think they're on the right
                 track.

   [Comment.24]  Susan: What drives the inclusion of a CH (or PSH)
                 security destination in the CH (or PSH), and where does
                 this value come from?  Is it security-policy driven?
                 Should there be a parameter in the Send.Request service
                 primitive to enable the bundle node to specify these
                 security destinations, if desired?

   [Comment.25]  Susan: We will eventually want to say more about
                 possibly providing confidentiality for some bundle
                 header fields in addition to simply providing payload
                 confidentiality.

   [Comment.26]  Howie: The security policy database will need to be
                 discussed somewhere. Does it belong in this document,
                 the bundle protocol spec., both, some other document?

   [Comment.27]  Editors: The paragraph below should be elsewhere;
                 unfortunately it isn't anywhere else yet, because it
                 was a security discussion that brought up the need for

Symington, et al.       Expires November 25, 2005              [Page 34]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

                 a "sender" field. This field has not yet made it into
                 the Bundle protocol. We must coordinate with the Bundle
                 Protocol spec authors to insert this text into the
                 Bundle Protocol. I have it here for now so it is at
                 least somewhere.

   [Comment.28]  Editors: These are initial thoughts and may be wrong,
                 or changed!

   [Comment.29]  Editors: These are really placeholders; very sketchy at
                 this point.

   [Comment.30]  Add DSS, with variations for entire bundle, head of
                 bundle... (should use of DSS be the default?  Over
                 entire bundle or just front?)

   [Comment.31]  Editors: this one is more efficient if we're not
                 pkcs1v1.5 compliant.

   [Comment.32]  Editors: we need another name, or else have to explain
                 what TP expands to...:-)

   [Comment.33]  This explanation needs to be more detailed, saying
                 exactly what parts of the canonical form of the bundle
                 each authenticator is calculated over.

   [Comment.34]  Editors: It isn't clear what entity decides the size of
                 the payload segments and breaks the payload into these
                 segments--the source bundle node or the source bundle
                 protocol agent?  If the source bundle node, why doesn't
                 it just send each of these segments as separate
                 bundles? if the source bundle node, then wouldn't the
                 send.Request primitive need to be modified to enable
                 the segment size to be specified? If the bundle
                 protocol agent decides the segment size, on what does
                 it base this decision?

   [Comment.35]  Howie: Should the TP segments sizes be fixed or random
                 (smaller than some maximum)? If they are fixed, what
                 compelling argument is there that any of them will get
                 through? If they are random in size (and we define a
                 TLV format for conveying the appropriate information)
                 then maybe something will get through.

   [Comment.36]  Editors: this still needs to be defined in the Bundle
                 Protocol.

   [Comment.37]  Howie: Eventually we will need to state where the

Symington, et al.       Expires November 25, 2005              [Page 35]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

                 security policy information/DB does get
                 discussed/specified.

Authors' Addresses

   Susan Flynn Symington
   The MITRE Corporation
   7515 Colshire Drive
   McLean, VA  22102
   US

   Phone: +1 (703) 983-7209
   Email: [email-masked]
   URI:   http://mitre.org/

   Stephen Farrell
   Trinity College Dublin
   Distributed Systems Group
   Department of Computer Science
   Trinity College
   Dublin
   Ireland

   Phone: +353-1-608-1539
   Email: [email-masked]

   Howard Weiss
   SPARTA, Inc.
   7075 Samuel Morse Drive
   Columbia, MD  21046
   US

   Phone: +1-410-872-1515 x201
   Email: [email-masked]

Symington, et al.       Expires November 25, 2005              [Page 36]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP 11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Symington, et al.       Expires November 25, 2005              [Page 37]
=0C
Internet-Draft          Bundle Security Protocol                May 2005

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Symington, et al.       Expires November 25, 2005              [Page 38]
=0C

------=_NextPart_000_012C_01C56070.88C0FD80--