Re: [dtn-interest] Hello from Brazil

["Birrane, Edward J." <[e-mail]>]

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 [[e-mail]] On Behalf Of Scott, Keith L. [[e-mail]]
Sent: Friday, January 31, 2014 1:26 PM
To: Templin, Fred L; [e-mail]
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:      [phone]
Communications Netowork Engineering & Analysis                  Email: [e-mail]
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: Templin, Fred L [mailto:[e-mail]]
Sent: Friday, January 31, 2014 12:14 PM
To: Scott, Keith L.; [e-mail]
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:[e-mail]] On Behalf Of Scott, Keith L.
Sent: Friday, January 31, 2014 8:12 AM
To: Prof. Marcelo; [e-mail]<mailto:[e-mail]>
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:      [phone]
Communications Netowork Engineering & Analysis                  Email: [e-mail]<mailto:[e-mail]>
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:[e-mail]] On Behalf Of Prof. Marcelo
Sent: Friday, January 31, 2014 7:14 AM
To: [e-mail]<mailto:[e-mail]>
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