Subject: [dtn-interest] Fwd: actual size of bundle

From: Muhammad Nasir Mumtaz Bhutta <[email-masked]>
Date: Mon, 6 Jun 2011 10:46:09 +0100

Hi,
Just a basic calculation on the size of a bundle.. ? ...

Has any one tried to calculate how many bytes of header information and
security result bytes are added to the actual payload data...

For example,
payload data size = 1 MB
ciphersuite = BAB-HMAC, PIB-RSA-SHA256, PCB-RSA-AES128-PAYLOAD-PIB-PCB

What will be the size of actual bundle after applying all the bundle headers
and bundle security headers and applying security operations and appending
results as well..

many thanks ..

regards,
Nasir

-- 
Muhammad Nasir Mumtaz
Lahore University Of Management Sciences

---

From: Muhammad Nasir Mumtaz Bhutta <[email-masked]>
Date: Mon, 6 Jun 2011 11:15:50 +0100

Hi,

For example,
payload data size = 1 MB

many thanks ..

regards,
Nasir

---

From: "Clark, Gilbert" <[email-masked]>
Date: Mon, 6 Jun 2011 12:12:53 -0400

What about grabbing two copies of <insert DTN implementation here> and using wireshark to determine this value exactly?

--Gilbert

From: [email-masked] [mailto:[email-masked]] On Behalf Of Muhammad Nasir Mumtaz Bhutta
Sent: Monday, June 06, 2011 6:16 AM
To: [email-masked]
Subject: [dtn-interest] Fwd: actual size of bundle

Hi,  

Has any one tried to calculate how many bytes of header information and security result bytes are added to the actual payload data... 

For example, 
payload data size = 1 MB 

What will be the size of actual bundle after applying all the bundle headers and bundle security headers and applying security operations and appending results as well.. 

many thanks .. 

regards,
Nasir

---

From: <[email-masked]>
Date: Mon, 6 Jun 2011 17:47:15 +0100

That's <insert Bundle implementation with security suite support here>, surely?

Significant Bundle trials to date - two in space, and one in northern Sweden - have not implemented the security architecture.

Lloyd Wood
http://sat-net.com/L.Wood/dtn

---

From: <[email-masked]>
Date: Tue, 7 Jun 2011 09:22:29 +0100

I've been corrected. Sorry, that's now _three_ in space.

The ISS Bioserve team published at IEEE Aerospace in March, and it turned up in IEEExplore in April.

Delay/Disruption-Tolerant Networking: Flight test results from the international space station
Jenkins, A. ; Kuzminsky, S. ; Gifford, K.K. ; Pitts, R.L. ; Nichols, K. ; 
BioServe Space Technol., Univ. of Colorado, Boulder, CO, USA

http://dx.doi.org/10.1109/AERO.2010.5446948 

"For the results described in this paper, the HOSC supports DTN by augmenting its command infrastructure for autonomous, delayed and disrupted commanding but does not perform the higher-layer responsibilities of a bundle protocol agent such as bundle routing, custody transfer, bundle quality of service, or the bundle security protocol."

No discussion of error detection/mitigation.

>> What will be the size of actual bundle after applying all the bundle headers and bundle security headers and applying security operations and appending results as well.. 

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: Johannes Morgenroth <[email-masked]>
Date: Tue, 07 Jun 2011 11:07:39 +0200

> Significant Bundle trials to date - two in space, and one in northern Sweden - have not implemented the security architecture.

Our implementation of the bundle protocol already has implemented the
bundle security protocol with BAB, PIB and PCB. So use IBR-DTN and
wireshark to look at the resulting overhead.

http://www.ibr.cs.tu-bs.de/projects/ibr-dtn/
(For easy entry ubuntu / debian packages are available.)

Regards,
Johannes

-- 
Johannes Morgenroth     Institut fuer Betriebssysteme und Rechnerverbund
Tel.: +49-531-391-3249                           Muehlenpfordtstrasse 23
Fax.: +49-531-391-5936      TU Braunschweig         D-38106 Braunschweig

---

From: <[email-masked]>
Date: Tue, 7 Jun 2011 10:25:18 +0100

Great.

Have you implemented the reliability suite and double wrapping
as described in
http://tools.ietf.org/search/draft-irtf-dtnrg-bundle-checksum
and the Bundle of Problems paper?

> Our implementation of the bundle protocol already has 
> implemented the bundle security protocol with BAB, PIB and 
> PCB. So use IBR-DTN and wireshark to look at the resulting overhead.
>

---

From: Andrew J Jenkins <[email-masked]>
Date: Tue, 07 Jun 2011 08:38:06 -0600

Hi Lloyd,

> BioServe Space Technol., Univ. of Colorado, Boulder, CO, USA

I'm "Jenkins, A"(ndrew).  You are correct, we didn't mention error 
detection/mitigation.  Apologies for the oversight.

The convergence layer adapter we used provided error detection: simple 
CRC16 over each bundle (a layer beneath BP).  Layers beneath that include 
CCSDS checkwords.

As you've pointed out in the past, this doesn't preclude agent programming 
errors or memory errors from corrupting bundles.  We've sent hundreds of 
thousands of bundles this way and haven't encountered any application 
corruption.  If we have had bundle corruption, it's been fixed by custodial 
retransmission.  Our reliability requirements tolerate memory errors 
causing crashes once-every-few-months so we just use COTS DDR SDRAM.

When we use this system to transfer files, the files themselves include 
md5sums and those are checked by the file transfer application (a layer 
above BP).

The work described in that paper preceded any BSP implementation work that 
I am aware of in the NASA or CCSDS area.  However, in follow-on work we've 
deployed an implementation of the BSP-Bundle Authentication Block that was 
developed by JHU-APL and JPL.  We're still using it to authenticate 
downlinked bundles.  Now that the BSP RFC is settled, I know that 
implementors are hard at work on putting an RFC-compliant security 
implementation into ION.

Regards,
Andrew

--
Andrew Jenkins
Professional Research Assistant / Software Developer
University of Colorado / Bioserve Space Technologies

---

From: <[email-masked]>
Date: Tue, 7 Jun 2011 16:29:36 +0100

(Ooops, your paper was March 2010, not 2011. Added a pointer
in the wiki.)

> As you've pointed out in the past, this doesn't preclude 
> agent programming errors or memory errors from corrupting 
> bundles.  We've sent hundreds of thousands of bundles this 
> way and haven't encountered any application corruption.

...that you know of, surely? Error detection can be
difficult, particularly when the bundle protocol does
no detection itself.

> If we have had bundle corruption, it's been fixed by
> custodial retransmission. 

Some questions for clarity: without a reliability check, if
you only ran md5sum on files being transferred, not on all
bundles, how do you detect bundle corruption for custody
retransmission to take place? Does the CLA using CRC16
signal to the bundle agent that a bundle is corrupted,
rather than just dropping it?

Use of CRC16 across a bundle implies small (<10K) payloads and
bundles; it would seem a bit weak and collision-prone across the
140KB you compute in Eqn. 1 as the minimum efficient bundle
size.

(The bundle protocol does not mandate any checks before
accepting custody.)

> When we use this system to transfer files, the files 
> themselves include md5sums and those are checked by the file 
> transfer application (a layer above BP).

So you're checking the md5sum on a file after final delivery?

We included MD5 in Saratoga (much to SF's dismay -
that experience eventually fed into RFC6151). We've tested
it in orbit; details in:

Large File Transfers from Space using Multiple Ground Terminals and Delay-Tolerant Networking
http://dx.doi.org/10.1109/GLOCOM.2010.5683304

- we basically treated the created bundles as files which
Saratoga carried, and computed MD5 across the bundle before
sending. Not perfect, but analogous to an application
(the bundle agent) handing over data and expecting reliable
delivery.

It took over five minutes to run the sum computation
across our large file; we deliberately chose MD5 because it
is a lightweight reliability check suitable for the filesize,
but it's a low-end processor getting through far less than
a megabyte/second. Other stronger security algorithms would
take longer...

> The work described in that paper preceded any BSP 
> implementation work that I am aware of in the NASA or CCSDS 
> area.  However, in follow-on work we've deployed an 
> implementation of the BSP-Bundle Authentication Block that 
> was developed by JHU-APL and JPL.  We're still using it to 
> authenticate downlinked bundles.

Interesting! Do you have a writeup of that yet?

> Now that the BSP RFC is 
> settled, I know that implementors are hard at work on putting 
> an RFC-compliant security implementation into ION.

I have concerns over how large a code footprint and how
processor-intensive the security protocol implementation
will be for embedded systems - that is not a concern for
desktop Linux systems, which can also afford to reuse
database backends, interpreters, etc.

Having to implement the security framework, which may not
even be needed depending on the threat model faced, in
order to get some assurance of reliability from the bundle
protocol itself may be considered undesirable due to such
concerns.

However, implementing lightweight security or reliability
end-to-end entirely outside the bundle protocol, just as you
have done with application md5sums for files, is entirely
feasible, at which point implementing the bundle security
protocol is not required. The bundle protocol isn't trusted
to do reliability, so why trust it for security either?

Interesting stuff...

regards,

Lloyd Wood

CRC and MD5 - eminently real-world practical.

> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>

---

From: Andrew J Jenkins <[email-masked]>
Date: Tue, 07 Jun 2011 10:41:28 -0600

> (Ooops, your paper was March 2010, not 2011. Added a pointer

Thanks!

> difficult, particularly when the bundle protocol does

Yes, that is exactly right.  What I should say is that over the course of 
the experimental results reported in that paper, we did not receive any 
data for which the md5sum didn't match.  We received the data files we 
expected (although some required automatic custodial retransmission).

Since then, we continue to downlink a consistent manifest of files (the 
temps for the last hour, the disk-free for the last hour, ...).  We do 
monitor and ensure that those files are all received on the ground, and our 
software checks that those files have md5sums that match the md5sums 
written just before the file content in the bundle.

Finally, the data is used to generate plots of things like temperature that 
human operators periodically monitor and they don't observe ridiculous 
data; the temperatures are inconsistent with random bit flips that would 
hit most-significant-bits as often as least-significant-bits.

> rather than just dropping it?

No, the CLA just drops bundles that fail CRC16.

Custody retransmission (in our setup) happens when the current custodian 
has transmitted a bundle, waited a defined amount of time, and failed to 
effect custody transfer.  Waiting a defined amount of time is possible in 
our configuration but may not be available in other configurations.

So, things that fail CRC16 are dropped and then eventually retransmitted.

> (The bundle protocol does not mandate any checks before

Yes.  Our initial implementation did not do any checks before accepting 
custody.  It relied on CRC16 (and app-layer md5sums).  It's experimental.

Our follow-on, with-security-implementation, does do HMAC-SHA1 
authentication before accepting custody of downlinked bundles.  Not because 
I anticipated this argument, but because Ed and Scott were smart enough to 
implement it that way :-)

Now, things that fail CRC16 or HMAC-SHA1 are dropped and eventually 
retransmitted.

When our implementation sends the custody signal bundles on the uplink, it 
does not do BSP-BAB.  This was a deliberate decision because our uplink is 
very tiny.  In fact, the way our uplink works, including BSP-BAB halved our 
uplink bandwidth (as observed by BP) because each bundle would span two 
uplink commands.  We've never observed corruption on the ISS command 
uplink.  Certainly, different engineers with different reliability 
requirements could make different choices.

> So you're checking the md5sum on a file after final delivery?

Yes: inside our file transfer daemon, we receive the bundle from ION, pick 
out the md5sum from the beginning of the bundle payload, and then md5sum 
the rest of the bundle payload and compare.

> (the bundle agent) handing over data and expecting reliable

This sounds similar to our underlying convergence layer computing CRC16s, 
except for the vastly superior error-detection capacity of md5.  Your 
approach has the advantage that you wouldn't accept a bundle that was 
subtly corrupted in a way that it passed CRC16 but failed md5.

> a megabyte/second. Other stronger security algorithms would

Yep.  This is probably why lots of equipment uses a CRC16.

> Interesting! Do you have a writeup of that yet?

No, and I apologize for that.

> protocol itself may be considered undesirable due to such

Our payload is a 1GHz Linux box.  More constrained users will have to 
consider the trade off you mention.  The ION BSP developers are not 
targeting 1GHz Pentium 4s.

> to do reliability, so why trust it for security either?

Many users may indeed choose to rely on other layers for security.  While 
the argument that BSP-BAB is heavyweight may be true for some users, once 
you've got it, it does provide certain kinds of security and reliability 
that we trust.

Reliability: Above I discuss how our non-BSP setup could accept custody of 
a bundle with a valid CRC16 but invalid app-level md5, causing that file to 
be dropped.  But now, with BSP-BAB, it would have to have a valid CRC16 and 
HMAC-SHA1, but invalid md5, which is pretty hard.

Security: the HMAC-SHA1 authentication prevents someone else from 
pretending to be our payload and inserting a file into our ground systems. 
  The md5sum doesn't defend against that.

---

From: "Hooke, Adrian J (9000)" <[email-masked]>
Date: Wed, 8 Jun 2011 04:55:03 -0700

> I've been corrected. Sorry, that's now _three_ in space.

Four: DTN was successfully flight tested on the NASA's Earth Observing One (EO-1) spacecraft a few months ago. Known spaceflight tests so far include:

a. UK DMC in low Earth orbit
b. Deep Impact in deep space
c. International Space Station (DTN is operational 24x7 in two payloads) in low Earth orbit
d. EO-1 in polar Earth orbit

All of the NASA spaceflight tests have used the Open Source "ION" (Interplanetary Overlay Network) implementation of DTN, which is available from Open Channel and (soon) SourceForge.

We have also run DTN-over-IP via Cisco's Internet Router In Space (IRIS), which is operating on Intelsat 14 in geosynchronous orbit.

///adrian

Adrian J. Hooke
Manager: Space Disruption Tolerant Networking (DTN) Project
Space Communications and Navigation Office (SCaN)
Space Operations Mission Directorate
NASA Headquarters
Washington DC  20024-3210

---

From: <[email-masked]>
Date: Wed, 8 Jun 2011 13:08:37 +0100

Interesting news!

Do you have writeups/papers on the EO-1 LEO and
DTN-over-IRIS going-through-a-GEO-delay-pipe tests?

And, related to this thread and the three in-space tests
that didn't use the bundle security protocol, was the BSP
implemented and used in these tests? Last I read on this
list, ION didn't implement the BSP; once it's on
sourceforge, it would be easier to just check the code...

(Good to see you coming around to working with Cisco and
 supporting that whole IP-and-routers-in-space thing, by
 the way.)

thanks,

Lloyd Wood

> -----Original Message-----
> From: Hooke, Adrian J (9000) [mailto:[email-masked]] 
> Sent: 08 June 2011 12:55
> To: Wood L Dr (Electronic Eng)
> Cc: [email-masked]
> Subject: RE: [dtn-interest] Fwd: actual size of bundle
> Importance: High
> 
> Four: DTN was successfully flight tested on the NASA's Earth 
> Observing One (EO-1) spacecraft a few months ago. Known 
> spaceflight tests so far include:
> 
> c. International Space Station (DTN is operational 24x7 in 
> two payloads) in low Earth orbit d. EO-1 in polar Earth orbit
> 
> All of the NASA spaceflight tests have used the Open Source 
> "ION" (Interplanetary Overlay Network) implementation of DTN, 
> which is available from Open Channel and (soon) SourceForge.
> 
> We have also run DTN-over-IP via Cisco's Internet Router In 
> Space (IRIS), which is operating on Intelsat 14 in 
> geosynchronous orbit.
> 
> ///adrian
> 
> Adrian J. Hooke
> Space Communications and Navigation Office (SCaN) Space 
> Operations Mission Directorate NASA Headquarters Washington 
> DC  20024-3210
> 
> 
>

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 8 Jun 2011 07:21:59 -0500

Adrian,

Is there a  writeup on the EO-1 effort?  I have been trying to get something on this.  I have no clue as to what was actually done ... bundle sizes, images sizes, network configuration.  I thought that perhaps CFDP over DTN over LTP (over IP?) and 64K bundles that may have been causing back-channel congestion due to ACKing small bundles and a bunch of stuff to aggregate at the LTP layer to alleviate this.  However, without documentation, it is all speculation and not much that the community can learn.

- Will

On Jun 8, 2011, at 7:55 AM, Hooke, Adrian J (9000) wrote:

///adrian

Adrian J. Hooke

_______________________________________________
dtn-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/dtn-interest

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

---

From: "Kruse, Hans" <[email-masked]>
Date: Wed, 8 Jun 2011 09:05:10 -0400

Lloyd,
while we are all looking forward to the SourceForge option, the ION code is of course available (and has been for some time) as open source, at 

http://www.openchannelfoundation.org/projects/ION

so no need to wait to look at the code.

>> Operations Mission Directorate NASA Headquarters Washington 

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer Science
Chief Operating Officer, GRID Lab
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: Greg Troxel <[email-masked]>
Date: Wed, 08 Jun 2011 09:13:43 -0400

while we are all looking forward to the SourceForge option, the ION
  code is of course available (and has been for some time) as open
  source, at

How does this license:

  http://www.openchannelfoundation.org/project/print_license.php?group_id=381&license_id=61

qualify as open source?  It doesn't seem even close to meeting the open
source definition.

What license will the code be under at sourceforge?

---

From: "Kruse, Hans" <[email-masked]>
Date: Wed, 8 Jun 2011 09:54:08 -0400

Greg,
that would be a question for the folks at JPL who own the rights to the software.   Given the previous (export controlled) status of ION, OpenChannel is quite an improvement.

Hans Kruse, Professor

---

From: Greg Troxel <[email-masked]>
Date: Wed, 08 Jun 2011 10:09:17 -0400

"Kruse, Hans" <[email-masked]> writes:

> that would be a question for the folks at JPL who own the rights to
> the software.  Given the previous (export controlled) status of ION,
> OpenChannel is quite an improvement.

My point was that if a license is not open source it should not be
represented as being open source.  I certainly see the point that this
is progress.

My understanding is that sourceforge, as a core policy, only hosts code
under an approved open source (or perhaps Free/fsf) license.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Wed, 8 Jun 2011 08:23:07 -0700

Greg, has the term "open source" been formally defined in law somewhere?  If it has, and the distribution of ION via Open Channel doesn't conform to that definition, then I agree that saying ION is open source is a misrepresentation.  If not, then I think it would be more constructive to make do (for now) with what we've got, and spend a little less time complaining about the language in which we characterize it.

Wikipedia (certainly not a settled legal authority, but I think widely consulted) says "Open-source software (OSS) is computer software that is available in source code form: the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, improve and at times also to distribute the software.  Some open source licenses meet the requirements of the Open Source Definition. Some open source software is available within the public domain."  The Open Channel license for ION meets that rather loose definition.  We all agree that we want something better, and I am assured that it is coming.  Let's move on.

Scott

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Greg Troxel
> Sent: Wednesday, June 08, 2011 7:09 AM
> To: Kruse, Hans
> Subject: Re: [dtn-interest] Fwd: actual size of bundle
> 
> 
> represented as being open source.  I certainly see the point that this is
> progress.
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Jun 2011 11:31:47 -0400

On Wed, Jun 08, 2011 at 08:23:07AM -0700, Burleigh, Scott C (313B) wrote:
> Greg, has the term "open source" been formally defined in law somewhere?  

Well, the Open Source Initiative publishes the Open Source Definition:

    http://opensource.org/docs/osd

It's true, however, that the term "Open Source" is not a trade mark of
OSI.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 8 Jun 2011 13:02:55 -0400

> Greg, has the term "open source" been formally defined in law somewhere?  If it has, and the distribution of ION via Open Channel doesn't conform to that definition, then I agree that saying ION is…

Dear Scott;

I am not a lawyer, and this is not legal advice. I am also wearing no hats, and what follows is just my opinion. 

In practice "open source" means "released under a license accepted as such by the open source community." The two (sets of) licenses
that are almost universally so accepted are the BSD and the GPL. There is a general distrust of "roll your own" licenses, at least until they
have been poked and prodded sufficiently by the lawyers. 

The simplified BSD license was adopted by the IETF Trust, 

http://www.opensource.org/licenses/BSD-3-Clause with one clause omitted, i.e.,
http://www.opensource.org/licenses/BSD-2-Clause

and so it applies to code published in RFCs.

The GPL license is used by Linux. Note that v2 and v3 have rather different implications; many enterprises refuse to work on GPLv3 code.

http://www.opensource.org/licenses/gpl-2.0
http://www.opensource.org/licenses/gpl-3.0

My understanding is that the Linux kernel is entirely GPL 2.0. 

These licenses are built on copyright; in countries that allow for software patents (as the USA does at present) 
there may be patent rights on open source material. 

In general open source licenses such as these offer few restrictions on the use, copying and modification of licensed software (except that you typically can't 
remove the license itself if you publish the software), but differ on the treatment of derivative works.

I see several things in the ION License 4.0  which I think render it not open source :

- copying is limited ("Recipient may copy the Software only for private internal purposes ")
- modifications are limited ("Recipient may make Modifications to the Software only for non-commercial, private internal purposes")
- use is (unclearly) limited ("Any such attempt or use for public or commercial purposes will automatically terminate the rights granted under this License").

So, I would suggest that you just describe this software as widely available, and leave it as that. 

Regards
Marshall

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 8 Jun 2011 15:04:33 -0500

NASA Ames had a very nice open source summit at the end of March.  They also did a very good job of including remote participation throughout.

http://www.nasa.gov/open/source/

There was a lot of discussion regarding open source licensing and that you only want one or two.  There is also discussion on ITAR (International Traffic in Arms Regulations)  I believe there may be some output report generated.

http://www.nasa.gov/open/source/agenda/

The discussion pages are still up, but you may need gmail.

example:
https://docs.google.com/document/pub?id=1TagS_gwDhDfxjr7WpG78_aIcfoPO1tMXBPeCMEE3-Us

- Will

Scott

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
On Behalf Of Greg Troxel
Sent: Wednesday, June 08, 2011 7:09 AM
To: Kruse, Hans
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] Fwd: actual size of bundle

"Kruse, Hans" <[email-masked]<mailto:[email-masked]>> writes: