Received: from nmta2.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.215]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5AEQYV22787 for ; Fri, 10 Jun 2005 07:26:35 -0700 Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta2.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5AEQH0N007607 for ; Fri, 10 Jun 2005 07:26:25 -0700 Received: from [127.0.0.1] (dhcp-79-22-229.jpl.nasa.gov [137.79.22.229]) by xmta3.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5AEQCik012809 for ; Fri, 10 Jun 2005 07:26:16 -0700 Message-ID: <42A9A303.9030103@jpl.nasa.gov> Date: Fri, 10 Jun 2005 07:26:11 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Subject: Re: [dtn-security] SDNV References: <4253247634.4763442532@jpl.nasa.gov> In-Reply-To: <4253247634.4763442532@jpl.nasa.gov> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: dhcp-79-22-229.jpl.nasa.gov [137.79.22.229] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: 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 Received: from nmta2.jpl.nasa.gov (nmta2.jpl.nasa.gov [137.78.160.215]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j57LTZV04553 for ; Tue, 7 Jun 2005 14:29:35 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta2.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j57LTUoT001205 for ; Tue, 7 Jun 2005 14:29:30 -0700 Received: from jpl.nasa.gov (eis-msg-065.jpl.nasa.gov [137.78.160.102]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j57LTTN2027074 for ; Tue, 7 Jun 2005 14:29:30 -0700 Received: from [137.78.160.72] (Forwarded-For: [128.195.80.241]) by mailhost4.jpl.nasa.gov (mshttpd); Tue, 07 Jun 2005 14:29:29 -0700 From: John S Segui To: dtn-security@mailman.dtnrg.org Message-ID: <4253247634.4763442532@jpl.nasa.gov> Date: Tue, 07 Jun 2005 14:29:29 -0700 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal Content-Type: text/plain; charset=windows-1252 Content-Disposition: inline X-Source-IP: eis-msg-065.jpl.nasa.gov [137.78.160.102] X-Source-Sender: John.S.Segui-119079@jpl.nasa.gov X-AUTH: Internal IP Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id j57LTZV04553 Subject: [dtn-security] SDNV Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: 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 Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j57E3fV01986 for ; Tue, 7 Jun 2005 07:03:41 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 0C0CA14C18D for ; Tue, 7 Jun 2005 15:03:35 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A04466EC1C9; Tue, 07 Jun 2005 15:03:34 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id BC95C14C18D for ; Tue, 7 Jun 2005 15:03:34 +0100 (IST) Message-ID: <42A5AA42.8050006@cs.tcd.ie> Date: Tue, 07 Jun 2005 15:08:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Subject: Re: [dtn-security] Re: SDNV-new : OK References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <4295D547.9080808@cs.tcd.ie> <20050531172941.GA30682@pisco.cs.berkeley.edu> <20050601160110.GF9319@masaka.cs.ohiou.edu> <20050604202950.GC14707@masaka.cs.ohiou.edu> In-Reply-To: <20050604202950.GC14707@masaka.cs.ohiou.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.752) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A14466EC1C9 Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: 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 >>>dtn-security@mailman.dtnrg.org >>>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 * >>____________________________________________________________________ > > > > Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j57DfEV01850 for ; Tue, 7 Jun 2005 06:41:14 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 04D5614C01F for ; Tue, 7 Jun 2005 14:41:03 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A03A55E4020; Tue, 07 Jun 2005 14:41:03 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id CCD0614C01F for ; Tue, 7 Jun 2005 14:41:03 +0100 (IST) Message-ID: <42A5A4FB.6040607@cs.tcd.ie> Date: Tue, 07 Jun 2005 14:45:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <429CA44A.4000405@jpl.nasa.gov> In-Reply-To: <429CA44A.4000405@jpl.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.752) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A13A55E4020 Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: 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. Received: from masaka.cs.ohiou.edu (masaka.cs.ohiou.edu [132.235.3.154]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j54KTuV22416 for ; Sat, 4 Jun 2005 13:29:56 -0700 Received: from masaka.cs.ohiou.edu (localhost [127.0.0.1]) by masaka.cs.ohiou.edu (8.12.10+Sun/8.12.8) with ESMTP id j54KTovP013506 for ; Sat, 4 Jun 2005 16:29:51 -0400 (EDT) Received: (from mramadas@localhost) by masaka.cs.ohiou.edu (8.12.10+Sun/8.12.10/Submit) id j54KToNo013505 for dtn-security@mailman.dtnrg.org; Sat, 4 Jun 2005 16:29:50 -0400 (EDT) Date: Sat, 4 Jun 2005 16:29:50 -0400 From: Manikantan Ramadas To: dtn-security@mailman.dtnrg.org Message-ID: <20050604202950.GC14707@masaka.cs.ohiou.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <4295D547.9080808@cs.tcd.ie> <20050531172941.GA30682@pisco.cs.berkeley.edu> <20050601160110.GF9319@masaka.cs.ohiou.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: <20050601160110.GF9319@masaka.cs.ohiou.edu> User-Agent: Mutt/1.4.1i Subject: [dtn-security] Re: SDNV-new : OK Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: --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 > > dtn-security@mailman.dtnrg.org > > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (SunOS) iD8DBQFCog89OxoMRRosfTURAnArAKCDN5hMrebkhuAOPof3/Mlewl4BhgCeJZFA 6Dy2S6VRKEYkE61kpWb+40M= =u1NF -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- Received: from M4.sparta.com (IDENT:CxQKeaJqsmoGAN4Z51n3F8bQt7spO4id@M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j52BgQV31565 for ; Thu, 2 Jun 2005 04:42:26 -0700 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.1/8.13.1) with ESMTP id j52BgDTA003978; Thu, 2 Jun 2005 06:42:13 -0500 Received: from columbia.sparta.com ([157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id j52BgDfh009708; Thu, 2 Jun 2005 06:42:13 -0500 Received: from [127.0.0.1] (testjk3.columbia.ads.sparta.com [157.185.81.160]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id j52Bg76i009779; Thu, 2 Jun 2005 07:42:13 -0400 (EDT) Message-ID: <429EF08F.2010108@sparta.com> Date: Thu, 02 Jun 2005 07:42:07 -0400 From: Howard Weiss User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Burleigh CC: dtn-security@mailman.dtnrg.org, "'Stephen Farrell'" , "'Susan F. Symington'" Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. References: <200506011452.j51Eq1W19612@smtp-bedford.mitre.org> <429E4F93.4010502@jpl.nasa.gov> In-Reply-To: <429E4F93.4010502@jpl.nasa.gov> Content-Type: multipart/alternative; boundary="------------010103060304030206000502" Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: 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 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-- Received: from nmta1.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.214]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j520FRV10708 for ; Wed, 1 Jun 2005 17:15:27 -0700 Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j520FGGa010079; Wed, 1 Jun 2005 17:15:16 -0700 Received: from [127.0.0.1] (dhcp-79-22-229.jpl.nasa.gov [137.79.22.229]) by xmta1.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id j520FF9J010197; Wed, 1 Jun 2005 17:15:15 -0700 Message-ID: <429E4F93.4010502@jpl.nasa.gov> Date: Wed, 01 Jun 2005 17:15:15 -0700 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org CC: "'Howard Weiss'" , "'Stephen Farrell'" , "'Susan F. Symington'" Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec. References: <200506011452.j51Eq1W19612@smtp-bedford.mitre.org> In-Reply-To: <200506011452.j51Eq1W19612@smtp-bedford.mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-229.jpl.nasa.gov [137.79.22.229] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: 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 Received: from masaka.cs.ohiou.edu (masaka.cs.ohiou.edu [132.235.3.154]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j51G8JV07913 for ; Wed, 1 Jun 2005 09:08:19 -0700 Received: from masaka.cs.ohiou.edu (localhost [127.0.0.1]) by masaka.cs.ohiou.edu (8.12.10+Sun/8.12.8) with ESMTP id j51G8E9e023744 for ; Wed, 1 Jun 2005 12:08:14 -0400 (EDT) Received: (from mramadas@localhost) by masaka.cs.ohiou.edu (8.12.10+Sun/8.12.10/Submit) id j51G8EkS023743 for dtn-security@mailman.dtnrg.org; Wed, 1 Jun 2005 12:08:14 -0400 (EDT) Date: Wed, 1 Jun 2005 12:08:14 -0400 From: Manikantan Ramadas To: dtn-security@mailman.dtnrg.org Message-ID: <20050601160814.GH9319@masaka.cs.ohiou.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EemXnrF2ob+xzFeB" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [dtn-security] Re: SDNV-new - [Resend : Tabs aligned properly] Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: --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 > dtn-security@mailman.dtnrg.org > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (SunOS) iD8DBQFCnd1tOxoMRRosfTURAmEeAJ9dlboGkFL/SKvX2CA9IaoBTzvBowCfflVO WrssJPJMS4/JrdfsDrU0A/c= =0baR -----END PGP SIGNATURE----- --EemXnrF2ob+xzFeB-- Received: from masaka.cs.ohiou.edu (masaka.cs.ohiou.edu [132.235.3.154]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j51G1GV07859; Wed, 1 Jun 2005 09:01:16 -0700 Received: from masaka.cs.ohiou.edu (localhost [127.0.0.1]) by masaka.cs.ohiou.edu (8.12.10+Sun/8.12.8) with ESMTP id j51G1A9e023509; Wed, 1 Jun 2005 12:01:10 -0400 (EDT) Received: (from mramadas@localhost) by masaka.cs.ohiou.edu (8.12.10+Sun/8.12.10/Submit) id j51G1ArO023506; Wed, 1 Jun 2005 12:01:10 -0400 (EDT) Date: Wed, 1 Jun 2005 12:01:10 -0400 From: Manikantan Ramadas To: dtn-security@mailman.dtnrg.org Cc: dtn-dev@mailman.dtnrg.org Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new Message-ID: <20050601160110.GF9319@masaka.cs.ohiou.edu> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <4295D547.9080808@cs.tcd.ie> <20050531172941.GA30682@pisco.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CXFpZVxO6m2Ol4tQ" Content-Disposition: inline In-Reply-To: <20050531172941.GA30682@pisco.cs.berkeley.edu> User-Agent: Mutt/1.4.1i Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: --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 > dtn-security@mailman.dtnrg.org > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (SunOS) iD8DBQFCndvFOxoMRRosfTURAoleAJ4uyCeF4YTPsU3RYb4O/JOcWkEfVwCfWKiL qksXKlyi/tbrDQkCJwKy9ww= =7pUf -----END PGP SIGNATURE----- --CXFpZVxO6m2Ol4tQ-- Received: from smtp-bedford.mitre.org (smtp-bedford-x.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j51Eq5V07443 for ; Wed, 1 Jun 2005 07:52:05 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j51Eq4O19916 for ; Wed, 1 Jun 2005 10:52:04 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 659F1BF7C for ; Wed, 1 Jun 2005 10:52:04 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j51Eq1W19612; Wed, 1 Jun 2005 10:52:01 -0400 Message-Id: <200506011452.j51Eq1W19612@smtp-bedford.mitre.org> Received: from mm122433-pc.mitre.org (128.29.14.10) by mailhub1.mitre.org with SMTP id 18087357; Wed, 01 Jun 2005 10:51:59 -0400 From: "Susan F. Symington" To: Cc: "'Howard Weiss'" , "'Stephen Farrell'" , "'Susan F. Symington'" Subject: RE: [dtn-security] 00 version of the Bundle Security Protocol Spec. Date: Wed, 1 Jun 2005 10:51:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcVmCb2AhkZX95MqRDSH71NzztUD9QAB66XQ In-reply-to: <429CA44A.4000405@jpl.nasa.gov> Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: Scott: Some replies (below). -susan >-----Original Message----- >From: dtn-security-admin@mailman.dtnrg.org >[mailto:dtn-security-admin@mailman.dtnrg.org] On Behalf Of >Scott Burleigh >Sent: Tuesday, May 31, 2005 1:52 PM >To: dtn-security@mailman.dtnrg.org >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 Received: from smtp.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j51ECTV07190; Wed, 1 Jun 2005 07:12:29 -0700 Received: from smtp.cs.tcd.ie (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id C942399B; Wed, 1 Jun 2005 15:12:27 +0100 (IST) Received: from webmail.cs.tcd.ie (wilde.cs.tcd.ie [134.226.32.55]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 4CB645C1; Wed, 1 Jun 2005 15:12:27 +0100 (IST) Received: from 62.233.4.129 (SquirrelMail authenticated user sfarrel6) by webmail.cs.tcd.ie with HTTP; Wed, 1 Jun 2005 15:12:27 +0100 (IST) Message-ID: <14017.62.233.4.129.1117635147.squirrel@webmail.cs.tcd.ie> In-Reply-To: <429CDF24.9010907@jpl.nasa.gov> References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <4295D547.9080808@cs.tcd.ie> <20050531172941.GA30682@pisco.cs.berkeley.edu> <429CA577.8000705@jpl.nasa.gov> <20050531215551.GB30682@pisco.cs.berkeley.edu> <429CDF24.9010907@jpl.nasa.gov> Date: Wed, 1 Jun 2005 15:12:27 +0100 (IST) Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new From: stephen.farrell@cs.tcd.ie To: "Scott Burleigh" Cc: dtn-security@mailman.dtnrg.org, dtn-dev@mailman.dtnrg.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org X-Reply-To: stephen.farrell@cs.tcd.ie List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: > 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 > dtn-dev@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-dev > >