Subject: Re: [dtn-security] SDNV
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Date: Fri, 10 Jun 2005 07:26:11 -0700
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>

John S Segui wrote:

>I am currently working on a DTN simulation project and have read the interesting email exchanges regarding SDNVs. First, I would like to say that I agree with the current push to unify SDNV-8 and SDNV-16. However, while the proposed SDNV nicely allows for relatively large length fields, it has an upper limit in length. So my question is: is there any reason SDNV should not handle variable length fields of all sizes?
>
>One method for handling infinitely long fields is to nest SDNVs. For instance, make bit two of the SDNV discriminant byte signify whether the SDNV nests another SDNV. In this case, the “root” SDNV follows whatever agreed upon standard for root SDNV encoding but its numerical value represents the length (in bits) of the *length* field in the nested SDNV (e.g. SDNV{SDNV}, SDNV{SDNV{SDNV}}, etc.). This is somewhat similar to the proposed method of encoding the length of the following field inside an SDNV, but has the added benefit, through nesting, of allowing infinite length; thus avoiding the Y2.1K bug.
>
>An alternative (suggested by a co-worker) is to chain SDNVs together. For instance, let bit two of the SDNV’s discriminant byte signify whether the field overflowed into another SDNV.
>
>In conclusion, there appears no reason why we can’t have a standard fully scalable data type to handle all variable length fields, including ever-growing crypto keys. Also, neither suggested method seems more complex or simpler than the current method. Comments?
>  
>
This is a pretty elegant idea, John, especially the nested variant, but 
I don't think I'd favor changing.  One disadvantage of both these 
approaches is that you lose the second bit of the discriminant, reducing 
the maximum size of the value you can represent in one byte from 127 to 
63; having to use two bytes to encode values on a fairly common scale 
like 1-100 doesn't seem attractive.  At the same time, it's not clear 
that we'll need to be able to represent numeric values of infinite 
length in these protocols.  For some kinds of math research I can 
imagine the nested SDNV structure being pretty handy, but using the SDNV 
to encode the length of a field (such as an encryption key) lets us have 
fields whose lengths are up to (2^68) bytes; I think that is likely to 
be plenty.

Scott

From: John S Segui <[email-masked]>
To: [email-masked]
Date: Tue, 07 Jun 2005 14:29:29 -0700
Priority: normal
Subject: [dtn-security] SDNV
Sender: [email-masked]
Reply-To: [email-masked]

I am currently working on a DTN simulation project and have read the interesting email exchanges regarding SDNVs. First, I would like to say that I agree with the current push to unify SDNV-8 and SDNV-16. However, while the proposed SDNV nicely allows for relatively large length fields, it has an upper limit in length. So my question is: is there any reason SDNV should not handle variable length fields of all sizes?

One method for handling infinitely long fields is to nest SDNVs. For instance, make bit two of the SDNV discriminant byte signify whether the SDNV nests another SDNV. In this case, the “root” SDNV follows whatever agreed upon standard for root SDNV encoding but its numerical value represents the length (in bits) of the *length* field in the nested SDNV (e.g. SDNV{SDNV}, SDNV{SDNV{SDNV}}, etc.). This is somewhat similar to the proposed method of encoding the length of the following field inside an SDNV, but has the added benefit, through nesting, of allowing infinite length; thus avoiding the Y2.1K bug.

An alternative (suggested by a co-worker) is to chain SDNVs together. For instance, let bit two of the SDNV’s discriminant byte signify whether the field overflowed into another SDNV.

In conclusion, there appears no reason why we can’t have a standard fully scalable data type to handle all variable length fields, including ever-growing crypto keys. Also, neither suggested method seems more complex or simpler than the current method. Comments?

John SeGui

Date: Tue, 07 Jun 2005 15:08:02 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-security] Re: SDNV-new : OK
Sender: [email-masked]
Reply-To: [email-masked]

Just checking another thing on this.

For LTP and bundle security and generally anywhere
we'll have some kind of optional field/extension
mechanism this means we're now moving to a straight
TLV (tag/length/value) scheme with the length being
an SDNV.

While that's ok by me, it is a change and is slightly
less efficient in some cases.

For example, in LTP we previously had extensions
structured like:

    +--------+---------------///-+
    |ext-tag | SDNV-8 spec       |
    +--------+-------------------////-+
    |ext-tag | SDNV-8 spec            |
    +--------+-------------------////-+

Whereas now we'll have to have it as:

    +--------+---------------///--------------+
    |ext-tag | length (SDNV) | value (octets) |
    +--------+-------------------////-----------+
    |ext-tag | length (SDNV) | value (octets)   |
    +--------+-------------------////-----------+

The same will of course be true of other fields.

The inefficiency occurs when the tag is such that
the value's length is fixed and the value would
fit within an SDNV. In that case we're probably
using up just one additional byte. (We can't
omit the length since that's the only way that
code not supporting this tag can skip to the
next one.)

However, I'm fine with this approach - TLV being
the traditional route after all,
Stephen.

PS: If someone's got time/energy, it might be worthwhile
comparing this to the ASN.1 packed encoding rules (PER) for
integer values. I guess we're ending up fairly similar.

Manikantan Ramadas wrote:

> Hi folks,
> 
>   After an offline discussion with Scott, I have come around to joining the
> consensus for dropping the SDNV-8/SDNV-16s in favour of the proposed SDNV
> scheme (the 1/2/3/4/5/6/7/8) which allows an SDNV of total size atmost 9
> bytes with value range 0-2^68-1. We don't have a real feel for how
> frequently the range 4096-32767 is likely to be used in LTP, and our current
> speculations don't predict a large hit-ratio for the range. Therefore, 
> it seems better to be homogeneous with the rest of the bundle protocol suite
> and adopt the proposed SDNV scheme.
> 
> - Mani.
> 
> On Wed, Jun 01, 2005 at 12:01:10PM -0400, Manikantan Ramadas wrote:
> 
>>Folks,
>>
>>  My apologies for falling way beyond on this thread, but I have caught up
>>finally.
>>
>>To summarize this "one true SDNV" scheme,   
>>we have eaten up 4 bits into the SDNV discriminant at the cost of the
>>maximum size of SDNV; it was 2^1024-1, which now becomes 2^68-1.
>>
>>I tend to agree with the general consensus in this thread that we should
>>probably quit worrying about fitting cryptographic keys in an SDNV, as they
>>are ever bit hungry, and it is only a matter of time before they overflow
>>any SDNV scheme we offer. It seems like a good idea for crypto. fields in
>>the DTN security specs, LTP extension specs, and other places to be encoded
>>to have their length field be an SDNV, and have the data of the indicated
>>length follow. Good.
>>
>>I think Rajesh mentioned that the real value of the SDNV scheme shows up
>>only for relatively smaller values. I tend
>>to agree with that, and hence would like to point out a key point that was
>>missing in our discussion here. SDNV-16's were designed to let you store
>>values from 128-32767 in just two octets (as opposed to SDNV-8 - the original
>>SDNV - which takes 2 octets for 128-255, 3 octets for 256-65535). SDNV16s,
>>as you can see, were designed to be optimal for data typically falling in
>>this range 128-32767. Note that they do need two bytes even to store data in
>>the range 0-127, and less optimal for this range compared to SDNV8s.
>>
>>With our current proposal, we can store only values from 128-4095 in two
>>octets, and requires three octets for 4096-2^20-1. While this is clearly
>>more optimal than SDNV8's, it is not so when compared to SDNV16s.
>>Laying them out :
>>
>>	Octets Required			SDNV16			proposed SDNV
>>    ---------------         ------			-------------
>>    	1					  --			0-127					
>>    	2					0-32767			128-4095
>>		3					32768-65535		4096-2^20-1
>>        4					2^16-2^24-1		2^20-2^28-1
>>        5					2^24-2^32-1		2^28-2^36-1
>>		..........
>>
>>Note that the way SDNV16 is defined, it always needs atleast 2 octets to
>>encode. 
>>
>>So, when we go to the octets required field being greater than 4, the
>>benefits of eating into the discriminant begin to show. It is the 2 octet
>>case that makes me a little nervous about the new scheme. It costs an octet
>>more for values in the range 4096-32767. We have quite a few fields like 
>>blockoffsets and chunk length, in LTP reception reports that might fall in
>>this range, and we lose the benefits of SDNV16 with this scheme. If those
>>fields take values greater than 32768, the new scheme beats it, sure. 
>>
>>Hence I can't yet make up my mind on giving away SDNV16's altogether. That
>>said, I am in principle, in favor of having a one true SDNV scheme that
>>would make life simpler. But can't make up my mind just yet on how
>>frequently the range 4096-32767 is likely to be used in LTP.
>>
>>Thoughts?
>>
>>- Mani.
>>
>>On Tue, May 31, 2005 at 10:29:41AM -0700, Michael Demmer wrote: 
>>
>>>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.
>>>_______________________________________________
>>>dtn-security mailing list
>>>[email-masked]
>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-security
>>
>>-- 
>>"'Beauty is truth, truth beauty,'--that is all
>>  Ye know on earth, and all ye need to know." - John Keats
>>____________________________________________________________________
>>  
>>* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
>>____________________________________________________________________
> 
> 
> 
> 

Date: Tue, 07 Jun 2005 14:45:31 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Sender: [email-masked]
Reply-To: [email-masked]

Foks,

Catching up after a week of sporadic access...

Scott Burleigh wrote:

> Susan F. Symington wrote:
> 
>> All,
>> Attached is our first draft of the DTN Bundle Security Protocol 
>> Specification. Please read it and provide comments.
> Hi. I've got a few comments on the substance of the spec, but not many; 
[...]

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

That's not usual IETF practice and could run afoul of RFC
editor procedures. Better to just number sections that
need to be referenced unless you like being a guinea pig.

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

Nope. We've agreed that the security *protocol* stuff is in the
separate draft. The base spec still has to include whatever
security considerations apply since otherwise an implementer
who's not coding up the security protocol will miss out on
all that good advice.

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

Whatever. So long as the procedures are informative and the
protocol specs. normative. (Note: I've no problem if the
procedures are RECOMMENDED or even if implementations
MUST produce the same outputs, but there's no reason
everyone's code has to have the same abstract APIs etc.)

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

Not really. Generally a CH will be stripped at the CH-dest.
I could probably invent some kind of shared secret case
where retaining it is necessary but it'd be a corner case.
(Note though that we've yet to analyse the CH/PSH combinations
so some use case might crop up there. Ditto for IBE I
suppose.)

There's currently no extension with the semantics "this
bundle used to be encrypted & I decrypted it & here's how".
I'd be surprised if that were worthwhile though.

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

The PSH case is different. For signature schemes its quite
possible that many nodes could check the correctness of the
signature bits, but only for some nodes to be able to check
key/revocation status. In that case, it does make sense to
allow nodes after the PSH-dest to see/check the PSH. With
MACs there'll be similar cases which arise if/when we get
to sort-of-secure-multicast.

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

See separate thread.

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

As Susan said the canonical form isn't necessarily transmitted ever
so I think we mean the same thing. We'll probably disagree about
how easy it is though, since in my experience this is the hardest
thing to get right for any data integrity service.

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

Not quite! To the extent that it makes no reference to BAH/CH/PSH
you could argue that security policy discussion really has to
be in the base spec since that's where the reader/coder starts
and is as far as many will get.

Seems wrong to have a MUST type reference to the security protocol
spec from the base spec which is what you'll otherwise need.

Stephen.

Date: Sat, 4 Jun 2005 16:29:50 -0400
From: Manikantan Ramadas <[email-masked]>
To: [email-masked]
Subject: [dtn-security] Re: SDNV-new : OK
Sender: [email-masked]
Reply-To: [email-masked]

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

Hi folks,

  After an offline discussion with Scott, I have come around to joining the
consensus for dropping the SDNV-8/SDNV-16s in favour of the proposed SDNV
scheme (the 1/2/3/4/5/6/7/8) which allows an SDNV of total size atmost 9
bytes with value range 0-2^68-1. We don't have a real feel for how
frequently the range 4096-32767 is likely to be used in LTP, and our current
speculations don't predict a large hit-ratio for the range. Therefore,=20
it seems better to be homogeneous with the rest of the bundle protocol suite
and adopt the proposed SDNV scheme.

- Mani.

On Wed, Jun 01, 2005 at 12:01:10PM -0400, Manikantan Ramadas wrote:
> Folks,
>=20
>   My apologies for falling way beyond on this thread, but I have caught up
> finally.
>=20
> To summarize this "one true SDNV" scheme,  =20
> we have eaten up 4 bits into the SDNV discriminant at the cost of the
> maximum size of SDNV; it was 2^1024-1, which now becomes 2^68-1.
>=20
> I tend to agree with the general consensus in this thread that we should
> probably quit worrying about fitting cryptographic keys in an SDNV, as th=
ey
> are ever bit hungry, and it is only a matter of time before they overflow
> any SDNV scheme we offer. It seems like a good idea for crypto. fields in
> the DTN security specs, LTP extension specs, and other places to be encod=
ed
> to have their length field be an SDNV, and have the data of the indicated
> length follow. Good.
>=20
> I think Rajesh mentioned that the real value of the SDNV scheme shows up
> only for relatively smaller values. I tend
> to agree with that, and hence would like to point out a key point that was
> missing in our discussion here. SDNV-16's were designed to let you store
> values from 128-32767 in just two octets (as opposed to SDNV-8 - the orig=
inal
> SDNV - which takes 2 octets for 128-255, 3 octets for 256-65535). SDNV16s,
> as you can see, were designed to be optimal for data typically falling in
> this range 128-32767. Note that they do need two bytes even to store data=
 in
> the range 0-127, and less optimal for this range compared to SDNV8s.
>=20
> With our current proposal, we can store only values from 128-4095 in two
> octets, and requires three octets for 4096-2^20-1. While this is clearly
> more optimal than SDNV8's, it is not so when compared to SDNV16s.
> Laying them out :
>=20
> 	Octets Required			SDNV16			proposed SDNV
>     ---------------         ------			-------------
>     	1					  --			0-127				=09
>     	2					0-32767			128-4095
> 		3					32768-65535		4096-2^20-1
>         4					2^16-2^24-1		2^20-2^28-1
>         5					2^24-2^32-1		2^28-2^36-1
> 		..........
>=20
> Note that the way SDNV16 is defined, it always needs atleast 2 octets to
> encode.=20
>=20
> So, when we go to the octets required field being greater than 4, the
> benefits of eating into the discriminant begin to show. It is the 2 octet
> case that makes me a little nervous about the new scheme. It costs an oct=
et
> more for values in the range 4096-32767. We have quite a few fields like=
=20
> blockoffsets and chunk length, in LTP reception reports that might fall in
> this range, and we lose the benefits of SDNV16 with this scheme. If those
> fields take values greater than 32768, the new scheme beats it, sure.=20
>=20
> Hence I can't yet make up my mind on giving away SDNV16's altogether. That
> said, I am in principle, in favor of having a one true SDNV scheme that
> would make life simpler. But can't make up my mind just yet on how
> frequently the range 4096-32767 is likely to be used in LTP.
>=20
> Thoughts?
>=20
> - Mani.
>=20
> On Tue, May 31, 2005 at 10:29:41AM -0700, Michael Demmer wrote:=20
> >=20
> > I took a pass at changing the language from the original LTP spec to
> > match my new proposal for SDNV encodings:
> >=20
> > ---
> >=20
> > Self-Delimiting Numeric Value (SDNV)
> >=20
> >    The design of LTP attempts to reconcile minimal consumption of
> >    transmission bandwidth with
> >=20
> >       (a) extensibility to satisfy requirements not yet identified and
> >       (b) scalability across a very wide range of network sizes and
> >           transmission payload sizes.
> >=20
> >    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.
> >=20
> >    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.
> >=20
> >    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.
> >=20
> >    The following table outlines the SDNV encoding for all value
> >    ranges, their associated discriminant encodings, and the total
> >    length in octets of the SDNV.
> >=20
> >    Value Range         Discriminant     SDNV Length=20
> >    ----------------    ------------     -----------
> >    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
> >=20
> >    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.
> >=20
> >    In general, though, we believe that SDNV representation of selected
> >    numeric values in LTP segments yields the smallest segment sizes
> >    without sacrificing scalability.
> > _______________________________________________
> > dtn-security mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-security
>=20
> --=20
> "'Beauty is truth, truth beauty,'--that is all
>   Ye know on earth, and all ye need to know." - John Keats
> ____________________________________________________________________
>  =20
> * Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
> ____________________________________________________________________

--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--DSayHWYpDlRfCAAQ
Content-Type: application/pgp-signature
Content-Disposition: inline

--DSayHWYpDlRfCAAQ--

Date: Thu, 02 Jun 2005 07:42:07 -0400
From: Howard Weiss <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: [email-masked], "'Stephen Farrell'" <[email-masked]>, "'Susan F. Symington'" <[email-masked]>
Subject: Re: [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.
--------------010103060304030206000502
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Scott,

Scott Burleigh wrote:

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

At least for now, it sounds like this should be a separate DTN "assigned 
header numbers" ID/RFC so that it can easily be re-issued when needed 
rather than muddying the waters of the Bundle Protocol spec.  It 
probably should end up being an IANA function at some point - maybe when 
DTNRG moves out of the IRTF and becomes DTNWG in the IETF?

Howie

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

--------------010103060304030206000502
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">Scott,</font></font><br>
<br>
Scott Burleigh wrote:<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <blockquote type="cite"><br>
    </blockquote>
agree that the extension headers should be documented and explained in
the
    <br>
security spec, but how are we going to make sure that whatever type
value is
    <br>
assigned to these headers doesn't conflict with a type chosen for use
in the
    <br>
bundle protocol or for use in another extension header? I was
envisioning us
    <br>
placing the header types that we know of in a table in the Bundle
Protocol
    <br>
so when folks make up new headers, they would be aware of which types
are
    <br>
already reserved for use. If we don't have a master list of header
types
    <br>
somewhere, then we at least need a master list of documents that
contain all
    <br>
header types.
    <br>
    <br>
  </blockquote>
Yes, this is going to be a problem that we'll have to solve somehow.&nbsp;
But I don't think having a master list in the Bundle Protocol spec is
the answer: at some point that document is going to need to be an RFC,
and we don't want to have to be submitting new versions of that RFC
every time we come up with a new extension header.&nbsp; Some sort of
central naming and numbering authority is needed; if not IANA, then
we'll need to find another or invent our own.<br>
</blockquote>
At least for now, it sounds like this should be a separate DTN
"assigned header numbers" ID/RFC so that it can easily be re-issued
when needed rather than muddying the waters of the Bundle Protocol
spec.&nbsp; It probably should end up being an IANA function at some point -
maybe when DTNRG moves out of the IRTF and becomes DTNWG in the IETF?<br>
<br>
Howie<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>

--------------010103060304030206000502--

Date: Wed, 01 Jun 2005 17:15:15 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
CC: "'Howard Weiss'" <[email-masked]>, "'Stephen Farrell'" <[email-masked]>, "'Susan F. Symington'" <[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:

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

>>Yes. In general, I think the clearest way to link these two 
>>documents in 
>>a cleanly decoupled fashion is this:
>>
>>1. Number most of the paragraphs in the BP spec individually, so that 
>>other documents can easily refer to them.
>>2. Include in the BP spec, somewhere at the start of the procedure 
>>specifications, a note to the effect that "the procedures mandated by 
>>this specification are neither exhaustive nor exclusive; supplementary 
>>DTN protocol specifications (including, but not restricted to, the 
>>Bundle Security Protocol) may require that additional measures 
>>be taken 
>>at specified junctures in these procedures; such additional measures 
>>shall not override or supersede the mandated BP procedures, 
>>except that 
>>they may in some cases make these procedures moot by requiring, for 
>>example, that implementations conforming to the supplementary protocol 
>>terminate the processing of a given incoming or outgoing 
>>bundle due to a 
>>fault condition recognized by that protocol."
>>3. Remove all other security-specific language from the BP spec.
>>4. Modify the Security spec to say things like "The following 
>>procedure 
>>MUST be performed immediately before the start of the BP procedure 
>>described in w.x.y.z: blah blah blah."
>>    
>>
>This works for me but only if the BP spec is not a moving target.  If its
>paragraph numberings are going to be in flux, then this will be a royal pain
>in the neck. At this point I'd like to keep our spec as is until we are sure
>the BP spec has settled.
>  
>
Sure.  But I think we are all in agreement that it is high time for that 
spec to stop being a moving target.  Waiting until you see some evidence 
of stability is entirely reasonable, but if we're not able to achieve 
that stability pretty darn toute de suite we are going to be facing some 
trouble.

>>>- need an at-most-once delivery parameter of the Register.request 
>>>primitive
>>>      
>>>
>>Here I think what's needed is a notion of extension parameters, along 
>>the same lines as the extension headers and extension procedures. That 
>>is, at the start of the service interface section of the BP 
>>spec we can 
>>say "the list of parameters specified for each BP service primitive is 
>>not to be understood as exhaustive or exclusive; supplementary DTN 
>>protocol specifications (including, but not restricted to, the Bundle 
>>Security Protocol) may require that implementations conforming 
>>to these 
>>protocols provide additional parameters with specified 
>>primitives." Then 
>>the Bundle Security Protocol can say which additional parameters are 
>>needed with which primitives, and what they mean, without constantly 
>>having to go back and tweak the BP spec whenever anything changes.
>>
>I see the merits of what you are proposing and I agree, but I'm not too
>clear on how it will work in practice at the API level given that there will
>be many different possible parameter lists that could be expected with a
>given send.request or data.indication primitive, depending on what
>combination of extension headers is in use. As the number of extension
>headers and extension protocols multiply, so does the number of possible
>different send.request primitive parameter combinations. Some document will
>have to tie these combinations together.
>
Sure, but that's an API problem rather than a spec problem.  I don't 
think it's an insoluble API problem, but I don't want to try proposing a 
solution right now; I just want to move ahead with the specs.

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

>>Other comments:
>>
>>1. The terminology is of course completely messed up by our 
>>decisions of 
>>two weeks ago. I will try to have a revised draft of the BP 
>>spec out by 
>>the end of next week, which may (or may not) help clarify everything.
>>    
>>
>Do you mean that the terminology in the Bundle Security Protocol spec is
>messed up?  I actually went through and changed it according to our
>decisions of two weeks ago. I intended for it to be in conformance with what
>we decided at Berkeley, so I would appreciate specific examples of where you
>think the terminology isn't correct.
>  
>
As I say, I'm hoping the revised BP draft will help.  For example, 
though, we resolved in Berkeley that "any entity that can send and/or 
receive bundles" is a node, so in section 1.2 I would say you can't 
assert that BPA1 is the first sender and BPA2 is the first recipient.  
Since only nodes send and receive bundles, BundleNodeX is the only 
possible first sender and there needs to be a BundleNodeW living above 
BPA2 that is the first recipient.

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

>>2. In section 2.2: is it your intent that the CH remains in the bundle 
>>even after decryption by the CH security destination, so that it can 
>>appear in the Data.indication at a bundle destination that isn't the 
>>decryptor? If so, what's the rationale for that? Likewise, 
>>does the PSH 
>>remain in the bundle even after verification by a PSH security 
>>destination that isn't the bundle destination?
>>    
>>
>Whether or not the CH remains in the bundle after decryption by the CH
>security destination is something that can be determined by security policy.
>We wanted to leave the option open to be able to keep it in if needed. Same
>with the PSH, though often it will be left in after checking because if a
>public key scheme is used to create the authenticator, many different hops
>along the way may be capable of checking the PSH value, so it would make
>sense to leave it in.
>  
>
Sure.

>>3. A note on 2.3: now that everything that sends or receives a 
>>bundle -- 
>>including routers -- is a node, this capability protects 
>>routers as well 
>>as end systems from replay.
>>    
>>
>
>I suppose it could be used to protect routers from replays that are destined
>specifically toward the router, but not from replays of bundles that the
>router is forwarding on to another destination.
>
Actually I think it would, precisely because of our new concept that "a 
bundle node is any entity that can send and/or receive bundles"; since a 
router is (can only be) a node like any other, it can specify 
"at-most-once-delivery" in its own registration request.  But this is 
another question on which I want *not* to engage in spirited debate 
right now.

>>4. In section 3.1: if you use really big keys, does this cause the 
>>security result (the result of applying a key in a calculation) to be 
>>really big as well? Too big to fit into 16 bytes? Do we need 
>>SDNVs to be 
>>coded for 1-2-4-8-16-32-64-128 for this purpose, or will the 
>>1-2-3-4-5-6-8-16 coding Mike proposed be sufficient?
>>    
>>
>As Stephen's email indicated, we can code the security result as two
>separate fields: length, value, so there is no security-related need to be
>able to accommodate the very large lengths with the above SDNV. This sounds
>like a good idea to me.
>  
>
Perfect.

>>6. Section 4.2: I don't think we really need to have a canonical form 
>>for bundles; instead, the Bundle Protocol Specification needs 
>>to define 
>>the canonical sequence in which bundle data elements are considered in 
>>the calculation of signatures, MACs, etc. The former is the physical 
>>form -- the on-the-wire format -- of the bundle, which doesn't matter; 
>>the latter is the *logical* form -- the Security Protocol's view -- of 
>>the bundle, which can always be readily computed from the 
>>former. You're 
>>already implicitly recognizing this by talking about headers that are 
>>"(logically) removed" from the bundle prior to calculation and 
>>endpoint 
>>ID strings that must be "substituted for their corresponding fields in 
>>the concatenated bundle header." I think it would greatly simplify the 
>>spec to simply say something like "the BSP view of a bundle shall 
>>comprise the logical concatenation of the following data elements" and 
>>then talk about performing calculations on the BSP view of the bundle. 
>>(You do something like this in the third paragraph of 4.3, third 
>>sentence. I think it's the right approach.)
>>    
>>
>Is this just a terminology issue?  I didn't think that "canonical form"
>meant strictly the on-the-wire-format.  What we are trying to define is the
>form of the bundle that will be used to calculate the PSH.
>  
>
It probably is just a language issue, but it's one to watch out for.  If 
I was confused, it's possible that some day someone else will be too.

>>7. Did we ever finally decide whether or not the Override Report-to 
>>Header was in the Bundle Protocol spec? I've lost track; I'll do some 
>>research in my email archive.
>>    
>>
>I don't recall either.
>  
>
At this point I'm figuring it will be an extension header.  We all 
agreed that it was potentially useful, but so is Source Routing; it 
doesn't seem indispensable, so I don't think it belongs in the BP spec.

>>8. In section 4.8: what do we do if one node that's registered at some 
>>endpoint ID says "at most once" and another one says it wants all 
>>copies? We can't simply "discard" the replay.
>>    
>>
>Thanks.  I think what needs to be done in this situation needs to be fixed
>and made clearer.  The replayed bundle MUST be forwarded to nodes that have
>registered without the "at most once" option but MUST NOT be forwarded to
>nodes that have registered with the "at most once" option.
>  
>
That sounds right.

>>9. In section 4.12: it's starting to look as if we could end up with a 
>>large and maybe open-ended number of possible bundle status 
>>values, and 
>>I don't know of many cases where these values aren't mutually 
>>exclusive. 
>>I'm thinking it's time to switch from having a Flags byte here 
>>to using 
>>a status code number; might as well make it a 16-bit number to 
>>allow for 
>>lots of extensions. And, again, the BP spec is going to have 
>>to say that 
>>the values it defines for this code are not the exclusive and 
>>exhaustive 
>>list.
>>    
>>
>Probably a good idea.  Again, though, the question arises as to how/where
>the codes are partitioned among the protocol extensions so that a single
>code isn't used to mean two different things.
>  
>
Yep; the naming and number authority issue again.

Scott

Date: Wed, 1 Jun 2005 12:08:14 -0400
From: Manikantan Ramadas <[email-masked]>
To: [email-masked]
Subject: [dtn-security] Re: SDNV-new - [Resend : Tabs aligned properly]
Sender: [email-masked]
Reply-To: [email-masked]

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

Sorry about the TABS being messed up in my previous mail. This one should be
easier on the eyes!

- Mani.

Folks,

  My apologies for falling way beyond on this thread, but I have caught up
finally.

To summarize this "one true SDNV" scheme,  =20
we have eaten up 4 bits into the SDNV discriminant at the cost of the
maximum size of SDNV; it was 2^1024-1, which now becomes 2^68-1.

I tend to agree with the general consensus in this thread that we should
probably quit worrying about fitting cryptographic keys in an SDNV, as they
are ever bit hungry, and it is only a matter of time before they overflow
any SDNV scheme we offer. It seems like a good idea for crypto. fields in
the DTN security specs, LTP extension specs, and other places to be encoded
to have their length field be an SDNV, and have the data of the indicated
length follow. Good.

I think Rajesh mentioned that the real value of the SDNV scheme shows up
only for relatively smaller values. I tend
to agree with that, and hence would like to point out a key point that was
missing in our discussion here. SDNV-16's were designed to let you store
values from 128-32767 in just two octets (as opposed to SDNV-8 - the origin=
al
SDNV - which takes 2 octets for 128-255, 3 octets for 256-65535). SDNV16s,
as you can see, were designed to be optimal for data typically falling in
this range 128-32767. Note that they do need two bytes even to store data in
the range 0-127, and less optimal for this range compared to SDNV8s.

With our current proposal, we can store only values from 128-4095 in two
octets, and requires three octets for 4096-2^20-1. While this is clearly
more optimal than SDNV8's, it is not so when compared to SDNV16s.
Laying them out :

Octets Required	    SDNV16         proposed SDNV
 ---------------    ------	       -------------
1                    --            0-127				=09
2                  0-32767         128-4095
3                  32768-65535     4096-2^20-1
4                  2^16-2^24-1     2^20-2^28-1
5                  2^24-2^32-1     2^28-2^36-1
		..........

Note that the way SDNV16 is defined, it always needs atleast 2 octets to
encode.=20

So, when we go to the octets required field being greater than 4, the
benefits of eating into the discriminant begin to show. It is the 2 octet
case that makes me a little nervous about the new scheme. It costs an octet
more for values in the range 4096-32767. We have quite a few fields like=20
blockoffsets and chunk length, in LTP reception reports that might fall in
this range, and we lose the benefits of SDNV16 with this scheme. If those
fields take values greater than 32768, the new scheme beats it, sure.=20

Hence I can't yet make up my mind on giving away SDNV16's altogether. That
said, I am in principle, in favor of having a one true SDNV scheme that
would make life simpler. But can't make up my mind just yet on how
frequently the range 4096-32767 is likely to be used in LTP.

Thoughts?

- Mani.

On Tue, May 31, 2005 at 10:29:41AM -0700, Michael Demmer wrote:=20
>=20
> I took a pass at changing the language from the original LTP spec to
> match my new proposal for SDNV encodings:
>=20
> ---
>=20
> Self-Delimiting Numeric Value (SDNV)
>=20
>    The design of LTP attempts to reconcile minimal consumption of
>    transmission bandwidth with
>=20
>       (a) extensibility to satisfy requirements not yet identified and
>       (b) scalability across a very wide range of network sizes and
>           transmission payload sizes.
>=20
>    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.
>=20
>    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.
>=20
>    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.
>=20
>    The following table outlines the SDNV encoding for all value
>    ranges, their associated discriminant encodings, and the total
>    length in octets of the SDNV.
>=20
>    Value Range         Discriminant     SDNV Length=20
>    ----------------    ------------     -----------
>    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
>=20
>    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.
>=20
>    In general, though, we believe that SDNV representation of selected
>    numeric values in LTP segments yields the smallest segment sizes
>    without sacrificing scalability.
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-security

--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

----- End forwarded message -----

--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--EemXnrF2ob+xzFeB
Content-Type: application/pgp-signature
Content-Disposition: inline

--EemXnrF2ob+xzFeB--

Date: Wed, 1 Jun 2005 12:01:10 -0400
From: Manikantan Ramadas <[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]

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

Folks,

  My apologies for falling way beyond on this thread, but I have caught up
finally.

To summarize this "one true SDNV" scheme,  =20
we have eaten up 4 bits into the SDNV discriminant at the cost of the
maximum size of SDNV; it was 2^1024-1, which now becomes 2^68-1.

I tend to agree with the general consensus in this thread that we should
probably quit worrying about fitting cryptographic keys in an SDNV, as they
are ever bit hungry, and it is only a matter of time before they overflow
any SDNV scheme we offer. It seems like a good idea for crypto. fields in
the DTN security specs, LTP extension specs, and other places to be encoded
to have their length field be an SDNV, and have the data of the indicated
length follow. Good.

I think Rajesh mentioned that the real value of the SDNV scheme shows up
only for relatively smaller values. I tend
to agree with that, and hence would like to point out a key point that was
missing in our discussion here. SDNV-16's were designed to let you store
values from 128-32767 in just two octets (as opposed to SDNV-8 - the origin=
al
SDNV - which takes 2 octets for 128-255, 3 octets for 256-65535). SDNV16s,
as you can see, were designed to be optimal for data typically falling in
this range 128-32767. Note that they do need two bytes even to store data in
the range 0-127, and less optimal for this range compared to SDNV8s.

With our current proposal, we can store only values from 128-4095 in two
octets, and requires three octets for 4096-2^20-1. While this is clearly
more optimal than SDNV8's, it is not so when compared to SDNV16s.
Laying them out :

	Octets Required			SDNV16			proposed SDNV
    ---------------         ------			-------------
    	1					  --			0-127				=09
    	2					0-32767			128-4095
		3					32768-65535		4096-2^20-1
        4					2^16-2^24-1		2^20-2^28-1
        5					2^24-2^32-1		2^28-2^36-1
		..........

Note that the way SDNV16 is defined, it always needs atleast 2 octets to
encode.=20

So, when we go to the octets required field being greater than 4, the
benefits of eating into the discriminant begin to show. It is the 2 octet
case that makes me a little nervous about the new scheme. It costs an octet
more for values in the range 4096-32767. We have quite a few fields like=20
blockoffsets and chunk length, in LTP reception reports that might fall in
this range, and we lose the benefits of SDNV16 with this scheme. If those
fields take values greater than 32768, the new scheme beats it, sure.=20

Hence I can't yet make up my mind on giving away SDNV16's altogether. That
said, I am in principle, in favor of having a one true SDNV scheme that
would make life simpler. But can't make up my mind just yet on how
frequently the range 4096-32767 is likely to be used in LTP.

Thoughts?

- Mani.

On Tue, May 31, 2005 at 10:29:41AM -0700, Michael Demmer wrote:=20
>=20
> I took a pass at changing the language from the original LTP spec to
> match my new proposal for SDNV encodings:
>=20
> ---
>=20
> Self-Delimiting Numeric Value (SDNV)
>=20
>    The design of LTP attempts to reconcile minimal consumption of
>    transmission bandwidth with
>=20
>       (a) extensibility to satisfy requirements not yet identified and
>       (b) scalability across a very wide range of network sizes and
>           transmission payload sizes.
>=20
>    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.
>=20
>    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.
>=20
>    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.
>=20
>    The following table outlines the SDNV encoding for all value
>    ranges, their associated discriminant encodings, and the total
>    length in octets of the SDNV.
>=20
>    Value Range         Discriminant     SDNV Length=20
>    ----------------    ------------     -----------
>    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
>=20
>    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.
>=20
>    In general, though, we believe that SDNV representation of selected
>    numeric values in LTP segments yields the smallest segment sizes
>    without sacrificing scalability.
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-security

--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--CXFpZVxO6m2Ol4tQ
Content-Type: application/pgp-signature
Content-Disposition: inline

--CXFpZVxO6m2Ol4tQ--

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

Scott:  

Some replies (below).

-susan

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Scott Burleigh
>Sent: Tuesday, May 31, 2005 1:52 PM
>To: [email-masked]
>Cc: 'Howard Weiss'; 'Stephen Farrell'
>Subject: Re: [dtn-security] 00 version of the Bundle Security 
>Protocol Spec.
>
>Susan F. Symington wrote:
>
[...]
>> -- need a new Confidentiality header type
>
>I don't think this should be in the Bundle Protocol (BP) spec, though. 
>All three security headers are extension headers; they should be 
>documented in the Security spec, just as any other extension header 
>should be documented in the spec that defines its content and use.
>

I agree that the extension headers should be documented and explained in the
security spec, but how are we going to make sure that whatever type value is
assigned to these headers doesn't conflict with a type chosen for use in the
bundle protocol or for use in another extension header? I was envisioning us
placing the header types that we know of in a table in the Bundle Protocol
so when folks make up new headers, they would be aware of which types are
already reserved for use. If we don't have a master list of header types
somewhere, then we at least need a master list of documents that contain all
header types.   

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

This works for me but only if the BP spec is not a moving target.  If its
paragraph numberings are going to be in flux, then this will be a royal pain
in the neck. At this point I'd like to keep our spec as is until we are sure
the BP spec has settled.

[...]

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

I see the merits of what you are proposing and I agree, but I'm not too
clear on how it will work in practice at the API level given that there will
be many different possible parameter lists that could be expected with a
given send.request or data.indication primitive, depending on what
combination of extension headers is in use. As the number of extension
headers and extension protocols multiply, so does the number of possible
different send.request primitive parameter combinations. Some document will
have to tie these combinations together. 

>> - need to add a sender field to the primary bundle header
>
>I don't think so. I went back through the document and didn't find any 
>mention of the "sender" being used for any purpose other than 
>security. 
>I think it belongs in the BAH.

If folks want it in the BAH that's fine with me, but I seem to recall from
previous meetings that there was consensus that the sender information is
useful for more than just security and should be in the primary bundle
header.  Debugging was one example of why it would be useful, I believe. I
don't have any problem putting the sender field in the BAH, but before we do
folks should think about whether they would want to know the sender even in
cases in which security is not in use. 

[...]

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

Do you mean that the terminology in the Bundle Security Protocol spec is
messed up?  I actually went through and changed it according to our
decisions of two weeks ago. I intended for it to be in conformance with what
we decided at Berkeley, so I would appreciate specific examples of where you
think the terminology isn't correct.

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

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

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

I suppose it could be used to protect routers from replays that are destined
specifically toward the router, but not from replays of bundles that the
router is forwarding on to another destination.  

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

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

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

Thanks!

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

Is this just a terminology issue?  I didn't think that "canonical form"
meant strictly the on-the-wire-format.  What we are trying to define is the
form of the bundle that will be used to calculate the PSH.

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

I don't recall either.

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

Thanks.  I think what needs to be done in this situation needs to be fixed
and made clearer.  The replayed bundle MUST be forwarded to nodes that have
registered without the "at most once" option but MUST NOT be forwarded to
nodes that have registered with the "at most once" option.

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

Probably a good idea.  Again, though, the question arises as to how/where
the codes are partitioned among the protocol extensions so that a single
code isn't used to mean two different things. 

[...]

-susan

Date: Wed, 1 Jun 2005 15:12:27 +0100 (IST)
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
From: [email-masked]
To: "Scott Burleigh" <[email-masked]>
Cc: [email-masked], [email-masked]
Importance: Normal
Sender: [email-masked]
Reply-To: [email-masked]

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

Ditto - so we should e.g. refactor the specs so that
security value and security parameters (when present)
consist of an SDNV for the length and then a field
for the value.

Not sure if we want to directly allow for the case
where a short MAC is directly encoded in an SDNV, but
I'll think about it - no need to hold up anything
on that basis alone,

Stephen.

>
> _______________________________________________
> dtn-dev mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-dev
>
>