Subject: Re: [dtn-interest] Hello from Brazil

From: <[email-masked]>
Date: Mon, 3 Feb 2014 09:19:46 +0000

Marcelo,

Just to expand a bit on Keith's pointer, the erasure codes we developed here at DLR to work underneath LTP are conceived for large latencies and lossy channels (e.g., deep-space optical links), where the use of feedback-based recovery techniques is ineffective.
In any case, I think that  you should clarify what you mean by error correction and the specific technology being assumed (RF or optics). As to the former, actually, physical layer already implements channel coding schemes that already provide almost-error free conditions in some scenarios, whereby erasure codes is really meant to recover the "remaining" losses.

Best Regards,

Tomaso

------------------------
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked]<mailto:[email-masked]>
http://www.dlr.de/kn/institut/abteilungen/san

From: dtn-interest [mailto:[email-masked]] On Behalf Of Prof. Marcelo
Sent: Friday, January 31, 2014 5:57 PM
Cc: [email-masked]
Subject: Re: [dtn-interest] Hello from Brazil

Hi Keith, thanks for your replay. I will take a look this documents.

hugs!

2014-01-31 Scott, Keith L. <[email-masked]<mailto:[email-masked]>>:
Marcelo,

Tomaso deCola from DLR has done some work with forward erasure coding underneath the Licklider Transmission Protocol (LTP), one of the 'convergence layers' underneath the DTN Bundle Protocol.  One of his more recent briefings on the topic is on the CCSDS Collaborative Work Environment (CWE) at http://cwe.ccsds.org/sis/docs/SIS-DTN/Meeting%20Materials/2013/Fall%20--%20San%20Antonio/LTP_w_EC.pdf

In terms of security protocol work, the IRTF is working to revise the Bundle Security Protocol to produce a 'streamlined bundle security protocol'; the informational draft is available at http://tools.ietf.org/html/draft-irtf-dtnrg-sbsp-00.

                        Best regards,

                        --keith

Dr. Keith Scott                                                                                           Office: +1.703.983.6547<tel:%2B1.703.983.6547>
Chief Engineer, E535 J86A                                                                    Fax:      +1.703.983.7142<tel:%2B1.703.983.7142>
Communications Netowork Engineering & Analysis                  Email: [email-masked]<mailto:[email-masked]>
The MITRE Corporation<http://www.mitre.org/>                                                                        M/S H300
7515 Colshire Drive
McLean, VA 22102

Area Director, CCSDS<http://www.ccsds.org/> Space Internetworking Services<http://cwe.ccsds.org/sis/default.aspx>

MITRE self-signs its own certificates.  Information about the MITRE PKI Certificate Chain is available from http://www.mitre.org/tech/mii/pki/

From: dtn-interest [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Prof. Marcelo
Sent: Friday, January 31, 2014 7:14 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn-interest] Hello from Brazil

Hello Everybody, how are you?

My name is Marcelo Guido, and I'm from Brazil. I study at UNIFESP (Federal University of Sao Paulo). For my master degree i´m studing the security of DTN's. I read some papers, like Ivancic (2010 - Security Analysis of DTN Architecture and Bundle Protocol Specification for Space-Based Networks), Ntareme and Domancich (2011 - Security and performance aspects of Bytewalla: A Delay Tolerant Network on smartphones). Now I´m reading the paper of Wood, Eddy and Holliday (2009 - A Bundle of Problems.

I found this subject very interesting. In a meeting with my guiding, we talk about the question of error correction. Some of you are researching on this area of knowledge? Is this a promising area of research?

Sorry by terrible english...:-)

Hugs!
Marcelo Guido

---

From: "Prof. Marcelo" <[email-masked]>
Date: Mon, 3 Feb 2014 08:46:50 -0200

Hi Emmanuel!

Thanks! I will read this paper.

Hugs

2014-01-31 LOCHIN Emmanuel <[email-masked]>:

>
> Hi Marcelo
>
> You might also be interested in this work :
> http://oatao.univ-toulouse.fr/4111/
> where an on-the-fly erasure coding scheme has been implemented and tested
> over a DTN network.
>
> Emmanuel
>
> Le Vendredi 31 Janvier 2014 17:57 CET, "Prof. Marcelo" <
> [email-masked]> a écrit:
>
> > 2014-01-31 Scott, Keith L. <[email-masked]>:
> >
> > >  Marcelo,
> > >
> > >
> > >
> > > Tomaso deCola from DLR has done some work with forward erasure coding
> > > underneath the Licklider Transmission Protocol (LTP), one of the
> > > 'convergence layers' underneath the DTN Bundle Protocol.  One of his
> more
> > > recent briefings on the topic is on the CCSDS Collaborative Work
> > > Environment (CWE) at
> > >
> http://cwe.ccsds.org/sis/docs/SIS-DTN/Meeting%20Materials/2013/Fall%20--%20San%20Antonio/LTP_w_EC.pdf
> > >
> > >
> > >
> > > In terms of security protocol work, the IRTF is working to revise the
> > > Bundle Security Protocol to produce a 'streamlined bundle security
>
> > > protocol'; the informational draft is available at
> > > http://tools.ietf.org/html/draft-irtf-dtnrg-sbsp-00.
> > >
> > >
> > >
> > >                         Best regards,
> > >
> > >
> > >
> > >                         --keith
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *Dr. Keith Scott*
> > > Office: +1.703.983.6547
> > >
> > > Chief Engineer, E535J86A
> > > Fax:      +1.703.983.7142
> > >
> > > Communications Netowork Engineering & Analysis                  Email:
> > > [email-masked]
> > >
> > > The MITRE Corporation <http://www.mitre.org/>
> > >                                                            M/S H300
> > >
> > > 7515 Colshire Drive
> > >
> > > McLean, VA 22102
> > >
> > >
> > >
> > > Area Director, CCSDS <http://www.ccsds.org/> Space Internetworking
>
> > > Services <http://cwe.ccsds.org/sis/default.aspx>
> > >
> > >
> > >
> > > MITRE self-signs its own certificates.  Information about the MITRE PKI
> > > Certificate Chain is available from http://www.mitre.org/tech/mii/pki/
> > >
> > >
> > >
> > >
> > >
> > > *From:* dtn-interest [mailto:[email-masked]] *On
> Behalf Of
> > > *Prof. Marcelo
> > > *Sent:* Friday, January 31, 2014 7:14 AM
> > > *To:* [email-masked]
> > > *Subject:* [dtn-interest] Hello from Brazil
> > >
> > >
> > >
> > > My name is Marcelo Guido, and I'm from Brazil. I study at UNIFESP
> (Federal
> > > University of Sao Paulo). For my master degree i´m studing the
> security of
> > > DTN's. I read some papers, like Ivancic (2010 - Security Analysis of
> DTN
> > > Architecture and Bundle Protocol Specification for Space-Based
> Networks),
> > > Ntareme and Domancich (2011 - Security and performance aspects of
> > > Bytewalla: A Delay Tolerant Network on smartphones). Now I´m reading
> the
> > > paper of Wood, Eddy and Holliday (2009 - A Bundle of Problems.
> > >
> > >
> > >
> > > I found this subject very interesting. In a meeting with my guiding, we
> > > talk about the question of error correction. Some of you are
> researching on
> > > this area of knowledge? Is this a promising area of research?
> > >
> > >
> > >

---

From: "Prof. Marcelo" <[email-masked]>
Date: Mon, 3 Feb 2014 09:04:24 -0200

Hi Tomaso!

Thanks for your answer! Well, at this point of my studies, I am looking for
a problem to study. I finished my bibliography review, and, now, I´m
looking for the problem to study. Until now security of DTN's show me
fragile, and one point that my guiding ask me was "how the bundle protocol
works to identify if the packet was ok?" If I'm not wrong I told him that
the protocol don´t identify this, because it is delegated to under layers.
Well, The DTN is really new for me, maybe I can told him a bullshit. Our
ideia is create a midleware between application layer and bundle layer to
do error correction. Do you think that it is a good contribution to DTN?
What are the points relationated with security that still open and need to
be studing?

Hugs!

Marcelo

2014-02-03 <[email-masked]>:

>  Marcelo,
>
>
>
> Just to expand a bit on Keith's pointer, the erasure codes we developed
> here at DLR to work underneath LTP are conceived for large latencies and
> lossy channels (e.g., deep-space optical links), where the use of
> feedback-based recovery techniques is ineffective.
>
> In any case, I think that  you should clarify what you mean by error
> correction and the specific technology being assumed (RF or optics). As to
> the former, actually, physical layer already implements channel coding
> schemes that already provide almost-error free conditions in some
> scenarios, whereby erasure codes is really meant to recover the "remaining"
> losses.
>
>
>
> Best Regards,
>
>
>
> Tomaso
>
>
>
> ------------------------------------------------
> *Deutsches Zentrum für Luft- und Raumfahrt* (DLR)
> German Aerospace Center
> Institute of Communications and Navigation | Satellite Networks |
> Oberpfaffenhofen | 82234 Wessling | Germany
>
> *Tomaso de Cola, Ph.D.*
> Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 |
> [email-masked] <[email-masked]>
> *From:* dtn-interest [mailto:[email-masked]] *On Behalf Of
> *Prof. Marcelo
> *Sent:* Friday, January 31, 2014 5:57 PM
> *Cc:* [email-masked]
>
> *Subject:* Re: [dtn-interest] Hello from Brazil
>
>
>
> 'convergence layers' underneath the DTN Bundle Protocol.  One of his more
> *From:* dtn-interest [mailto:[email-masked]] *On Behalf Of
> *Prof. Marcelo
> My name is Marcelo Guido, and I'm from Brazil. I study at UNIFESP (Federal
> University of Sao Paulo). For my master degree i´m studing the security of
> DTN's. I read some papers, like Ivancic (2010 - Security Analysis of DTN
> Architecture and Bundle Protocol Specification for Space-Based Networks),
> Bytewalla: A Delay Tolerant Network on smartphones). Now I´m reading the
> talk about the question of error correction. Some of you are researching on

---

From: "Birrane, Edward J." <[email-masked]>
Date: Mon, 3 Feb 2014 13:36:44 -0500

Keith, Fred,

  I believe that SBSP, when promoted to RFC, should be a replacement for BSP as defined in RFC6257.  SBSP is a set of simplifications to BSP that allows full implementation in a larger variety of networking cases. There might exist very unique cases where more complex interactions are required, and those cases might also be served by SBSP, or by something else. But those cases should be the exceptions, not the rule.

  I envision SBSP as being part of a larger DTN security roadmap, consisting of, at least, the following.

1. A simpler protocol defining DTN security primitives, the draft of which is SBSP.

2. A separate document that describes required ciphersuites. This is in part to allow ciphersuite definitions to be updated without affecting the SBSP document itself.  This is also in part to allow for potentially describing required ciphersuites on a user-category by user-category basis.  I have found that a one-size-fits-all ciphersuite mandate is challenging across the diverse deployment opportunities for DTN.  Things such as signing with an asymmetric key may be mandatory for some deployments and not-implementable in others. So we are currently looking at identifying a few ciphersuite categories for this document and then implementations can claim to be compliant to a specific category. 

3. A "security cookbook" that describes how to take a variety of DTN protocol standards and combine them to reach the desired security effect. One example being the combination of SBSP with bundle-in-bundle encapsulation (BIBE) as one way to create a security tunnel. Neither SBSP nor BIBE should address this usage in their respective specifications;  the cookbook should describe how they may be combined to achieve a security result. 

The SBSP presentation from IETF 87  (http://www.ietf.org/proceedings/87/slides/slides-87-dtnrg-3.pdf) describes some of this rationale in more detail. 

-Ed

________________________________________
From: dtn-interest [[email-masked]] On Behalf Of Scott, Keith L. [[email-masked]]
Sent: Friday, January 31, 2014 1:26 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn-interest] Hello from Brazil

*My* understanding is the SBSP is intended to ‘replace’ BSP as defined in RFC6257.  I believe the rationale for this is as follows:

1.    RFC6257 (BSP) allows the specification of security endpoints  (essentially encryption and decryption points) as DTN EIDs.  Unfortunately, the interaction between such security endpoints and routing is not well-defined, meaning that unless DTN routers in the middle of the network understand and pay attention to the security blocks and their security EIDs, bundles could be routed ‘around’ the security destination to the bundle destination, and hence could arrive still encrypted.

a.     This is addressed in SBSP by the adjunct ‘bundle-in-bundle encapsulation’ (tunneling) mechanism.

2.    BSP allows for complex nesting of security mechanisms (including in particular payload confidentiality and extension security blocks).  Order of application becomes a real issue, and this gets coupled with #1 above to create a big gooey mess.

a.     I think encapsulation is the main mitigator here too, but there may be others?

3.    Interactions between encryption and the endpoint dictionary can get problematic.

4.    BSP contains both the protocols and ciphersuite definitions.  Ciphersuites are apt to need to change / be obsoleted more rapidly than the protocol itself.

a.     I think the plan with SBSP is to break the ciphersuite definitions into a separate document.

Others may be able to elaborate on and/or correct the above.

Best regards,

                        --keith

Dr. Keith Scott                                                                                           Office: +1.703.983.6547
Chief Engineer, E535 J86A                                                                    Fax:      +1.703.983.7142
Communications Netowork Engineering & Analysis                  Email: [email-masked]
The MITRE Corporation<http://www.mitre.org/>                                                                        M/S H300
7515 Colshire Drive
McLean, VA 22102

From: Templin, Fred L [mailto:[email-masked]]
Sent: Friday, January 31, 2014 12:14 PM
To: Scott, Keith L.; [email-masked]
Subject: RE: [dtn-interest] Hello from Brazil

Hi Keith,

Do you know if ‘draft-irtf-dtnrg-sbsp’ is intended to either update or obsolete RFC6257?

Thanks - Fred

From: dtn-interest [mailto:[email-masked]] On Behalf Of Scott, Keith L.
Sent: Friday, January 31, 2014 8:12 AM
To: Prof. Marcelo; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] Hello from Brazil

Marcelo,

Tomaso deCola from DLR has done some work with forward erasure coding underneath the Licklider Transmission Protocol (LTP), one of the ‘convergence layers’ underneath the DTN Bundle Protocol.  One of his more recent briefings on the topic is on the CCSDS Collaborative Work Environment (CWE) at http://cwe.ccsds.org/sis/docs/SIS-DTN/Meeting%20Materials/2013/Fall%20--%20San%20Antonio/LTP_w_EC.pdf

In terms of security protocol work, the IRTF is working to revise the Bundle Security Protocol to produce a ‘streamlined bundle security protocol’; the informational draft is available at http://tools.ietf.org/html/draft-irtf-dtnrg-sbsp-00.

                        Best regards,

                        --keith

Dr. Keith Scott                                                                                           Office: +1.703.983.6547
Chief Engineer, E535 J86A                                                                    Fax:      +1.703.983.7142
Communications Netowork Engineering & Analysis                  Email: [email-masked]<mailto:[email-masked]>
The MITRE Corporation<http://www.mitre.org/>                                                                        M/S H300
7515 Colshire Drive
McLean, VA 22102

Hugs!
Marcelo Guido

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 03 Feb 2014 22:46:48 +0000

Just in case it helps speed things up...(given that the RG
are going quite slowly these days;-)

On 02/03/2014 06:36 PM, Birrane, Edward J. wrote:
> I believe that SBSP, when promoted to RFC, should be a replacement
> for BSP as defined in RFC6257.

We don't need to think in terms of replacing or obsoleting.
So long as we're in IRTF-land, these are all experimental
RFCs. Another experiment is just fine.

So SBSP or whatever does not have to try fully replace BSP,
(nor justify doing so), just include the bits you want.

S.

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 06:10:22 +0000

> I envision SBSP as being part of a larger DTN security roadmap

If someone could explain what the actual rest-of-DTN roadmap is at this point, if indeed there is one, that would be super.

DTN: difficult conditions introducing errors,yet no reliability checks to detect them.
DTN: synchronised clocks, yet no communications to synchronise them.
DTN: lots of encryption, yet no available processing power.

Road to nowhere, if you ask me...

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn-interest [[email-masked]] On Behalf Of Birrane, Edward J. [[email-masked]]
Sent: 03 February 2014 18:36
To: [email-masked]
Subject: Re: [dtn-interest] Hello from Brazil

Keith, Fred,

-Ed

Best regards,

                        --keith

Hi Keith,

Thanks - Fred

Marcelo,

                        Best regards,

                        --keith

Hugs!
Marcelo Guido
_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Johannes Morgenroth <[email-masked]>
Date: Tue, 04 Feb 2014 09:10:47 +0100

Hello Tomaso!

Am 03.02.2014 12:04, schrieb Prof. Marcelo:
> "how the bundle protocol works to identify if the packet was ok?"
You are right. That is not part of the RFC 5050 or RFC 4838.

But with some imagination the Bundle Security Protocol is adequate to
check for transmission errors. Each BAB provides data checking and
invalid bundles going to be dropped. If the standard ciphersuite
BAB-HMAC is too complex for your needs, you can define a CRC-like
ciphersuite which does not require any key.

Kind regards,
Johannes Morgenroth

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 08:30:46 +0000

Hello Johannes!

The approach we used actually goes beyond error detection (e.g., CRC). We developed a packet-layer coding strategy, as part of a shim layer placed between LTP and CCSDS-native layers, responsible for error detection and correction. To this end, some redundant packets are generated to improve the reliability of communication. Further to this, the "shim layer" actually implements a real protocol, whereby a header is appended to each encapsulated LTP segment. This header contains information for encoding/decoding functions and also implements a CRC-32 to avoid that bit errors are propagated to the upper layer once the decoding is completed. 
We preferred not to integrate the erasure coding functions within the bundle protocol to avoid additional complexity from an implementation point of view and to handle packet erasures as much closer to the link layer as possible in order to avoid more severe performance degradation in case of erasure propagation upwards in the protocol stack (e.g., the case where a bundle protocol is composed of several LTP segments). Ultimately this approach was also pursued to avoid that we have to resort to LTP ARQ mechanisms which can be very time-consuming in deep-space networks or in general over long links with non-negligible packet error rate.

Best Regards,

Tomaso

------------------------ 
Deutsches Zentrum für Luft- und Raumfahrt (DLR) 
German Aerospace Center 
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany 
Tomaso de Cola, Ph.D. 
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked] 
http://www.dlr.de/kn/institut/abteilungen/san 

> -----Original Message-----
> From: dtn-interest [mailto:[email-masked]] On Behalf Of
> Johannes Morgenroth
> Sent: Tuesday, February 04, 2014 9:11 AM
> But with some imagination the Bundle Security Protocol is adequate to check
> for transmission errors. Each BAB provides data checking and invalid bundles
> going to be dropped. If the standard ciphersuite BAB-HMAC is too complex
> for your needs, you can define a CRC-like ciphersuite which does not require
> any key.
> 
> Kind regards,
> Johannes Morgenroth
> 
>

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 12:20:03 +0000

"beyond error detection"?

there still needs to be an endtoend check to ensure that bundles have not been corrupted in transit.

the lack of reliability checking in the bundle protocol itself (and in LTP) requires the 'optional' security mechanisms, even if security per se is not desired.

Lloyd Wood

________________________________________
From: dtn-interest [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: 04 February 2014 08:30
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Hello from Brazil

Hello Johannes!

Best Regards,

Tomaso

------------------------

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 13:05:55 +0000

Hello Lloyd, 

I meant that our approach is aimed at delivering reliably "data" to BP/LTP, as such erasure encoding/decoding have to be performed, not only crc checking. Overall reliability/integrity of reconstructed ltp segments and bundles should be carried out by ltp and bp as you remarked.

T.
_______________________________________
Da: [email-masked] [[email-masked]]
Inviato: martedì 4 febbraio 2014 13.20
A: Cola, Tomaso de; [email-masked]
Cc: [email-masked]
Oggetto: RE: [dtn-interest] Hello from Brazil

Lloyd Wood

Hello Johannes!

Best Regards,

Tomaso

------------------------