Subject: [dtn-interest] Erasure Coding Extension Internet Drafts available for review.

From: John Zinky <[email-masked]>
Date: Tue, 4 Sep 2012 09:55:33 -0400

We would like to announce an extension to the DTN protocol to support fragmentation of large payloads in the case of highly disrupted networks. The technique introduces Forward Error Correcting Codes into a bundle extension block and defines the Random Binary FEC scheme, which is appropriate for situations with huge drop rates +90%. also other FEC schemes are supported, such as Block Parity.

The official IRTF drafts can be found at:
  http://tools.ietf.org/html/draft-irtf-dtnrg-zinky-erasure-coding-extension-00
  http://tools.ietf.org/html/draft-irtf-dtnrg-zinky-erasure-coding-objects-00
  http://tools.ietf.org/html/draft-irtf-dtnrg-zinky-random-binary-fec-scheme-00

Any comments would be welcome.

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Tue, 4 Sep 2012 09:36:15 -0500

John,
If I encrypt a bundle using PIB or PCB prior to FEC, will FEC work or, because you are now performing fragmentation after encryption, will FEC not be applicable.

In other words, It appears I can encrypt and FEC bundle, but can I FEC an encrypted bundle.  I think this needs to be clearly stated somewhere if it is not already.

Also, some ASCII Art would be useful - particularly in the extensions draft.  I've used JavE (Java Ascii Versatile Editor) in the past to ease the pain.
http://www.jave.de/#description

- Will

---

From: John Zinky <[email-masked]>
Date: Thu, 6 Sep 2012 13:36:45 -0400

> If I encrypt a bundle using PIB or PCB prior to FEC, will FEC work or, because you are now performing fragmentation after encryption, will FEC not be applicable.
When the Data Object is a DTN Bundle, the Bundle wire format (bit for bit) is sent to the decoding BPA.
When enough of the Data Object arrives to be decoded, the Data Object (the Bundle) is injected back into the DTN.
In some sense the erasure coding acts as a more reliable link across the DTN from the source BPA to the destination BPA. Whatever encryption that was used on the Bundle will still be on the decoded Bundle, the only difference is the Bundle will be in a different place.

So the bundle fragmentation and Reassembly rules in section 3.8 of the bundle-security draft do not apply, instead use the fragmentation rules in erasure-encoding-objects (section 4.3).

> In other words, It appears I can encrypt and FEC bundle, but can I FEC an encrypted bundle.  I think this needs to be clearly stated somewhere if it is not already.
One of the problems with the current bundle-security draft is it can not sign an individual extension block.
Erasure coding needs to guarantee the integrity of both the coefficient vector (extension block) and the encoded data (payload). Without the integrity guarantee, an adversary can inject a bundle an mess up the decoding process.

> http://www.jave.de/#description
Do you have any suggestions for which diagrams you would like to see?

---

From: manasi navare <[email-masked]>
Date: Thu, 6 Sep 2012 12:20:50 -0600

Can someone remove me from this mailing list?

On Sep 6, 2012 12:37 PM, "John Zinky" <[email-masked]> wrote:

On Sep 4, 2012, at 10:36 AM, Ivancic, William D. (GRC-RHN0) wrote:

> If I encrypt a bundle...
When the Data Object is a DTN Bundle, the Bundle wire format (bit for bit)
is sent to the decoding BPA.
When enough of the Data Object arrives to be decoded, the Data Object (the
Bundle) is injected back into the DTN.
In some sense the erasure coding acts as a more reliable link across the
DTN from the source BPA to the destination BPA. Whatever encryption that
was used on the Bundle will still be on the decoded Bundle, the only
difference is the Bundle will be in a different place.

So the bundle fragmentation and Reassembly rules in section 3.8 of the
bundle-security draft do not apply, instead use the fragmentation rules in
erasure-encoding-objects (section 4.3).

>
> In other words, It appears I can encrypt and FEC bundle, but can I FEC an
encrypted bundle. I...
One of the problems with the current bundle-security draft is it can not
sign an individual extension block.
Erasure coding needs to guarantee the integrity of both the coefficient
vector (extension block) and the encoded data (payload). Without the
integrity guarantee, an adversary can inject a bundle an mess up the
decoding process.

>
> Also, some ASCII Art would be useful - particularly in the extensions
draft. I've used JavE ...
Do you have any suggestions for which diagrams you would like to see?

>> We would like to announce an ...

---

From: Peter Lovell <[email-masked]>
Date: Thu, 06 Sep 2012 14:41:00 -0400

>sign an individual extension block.

Hi John,

the existing ESB mechanism can sign any arbitrary extension block.

The ES4 ciphersuite described in RFC 6257 does encryption rather than signing, but it's easy to create your own ciphersuite to do signing rather than encryption.

Regards.....Peter