Re: [dtn-interest] Comments on RFC 4838

Michael Noisternig <michael.noisternig@cased.de> Wed, 19 June 2013 12:21 UTC

Return-Path: <michael.noisternig@cased.de>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A3021F941D for <dtn-interest@ietfa.amsl.com>; Wed, 19 Jun 2013 05:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.517
X-Spam-Level:
X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUSawFT47bzI for <dtn-interest@ietfa.amsl.com>; Wed, 19 Jun 2013 05:21:17 -0700 (PDT)
Received: from lnx500.hrz.tu-darmstadt.de (lnx500.hrz.tu-darmstadt.de [130.83.156.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9A21F8F29 for <dtn-interest@irtf.org>; Wed, 19 Jun 2013 05:21:10 -0700 (PDT)
Received: from mail.cased.de (mail.cased.de [130.83.33.42]) by lnx500.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id r5JCL9IG001945 for <dtn-interest@irtf.org>; Wed, 19 Jun 2013 14:21:09 +0200 (envelope-from michael.noisternig@cased.de)
Received: from [130.83.33.155] (cased155.cased.tu-darmstadt.de [130.83.33.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cased.de (Postfix) with ESMTPSA id 129087FA01E for <dtn-interest@irtf.org>; Wed, 19 Jun 2013 14:11:17 +0200 (CEST)
Message-ID: <51C19FE3.1070302@cased.de>
Date: Wed, 19 Jun 2013 14:11:15 +0200
From: Michael Noisternig <michael.noisternig@cased.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: dtn-interest@irtf.org
References: <51C0232F.3060607@cased.de> <52C28268-AA24-4A27-81F1-E620A282B0A3@ibr.cs.tu-bs.de> <29788_1371626940_r5J7SxAP004703_51C15E21.9040104@netlab.tkk.fi>
In-Reply-To: <29788_1371626940_r5J7SxAP004703_51C15E21.9040104@netlab.tkk.fi>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.19.120716
X-PMX-RELAY: outgoing
Subject: Re: [dtn-interest] Comments on RFC 4838
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-interest>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 12:21:22 -0000

Hi Jörg,

thank you for your response.

First of all I would like to apologize as I have probably been behaving 
a bit like the elephant in the room. I should have been not so 
presumptuous in assuming that you are not aware of the issues raised. I 
also should have checked your mailing list discussions beforehand... my 
bad. Finally, I guess I was taking "RFC" a bit too literally. I do want 
to raise here to my defense that I was originally looking at the 
documents from a security perspective, and it was actually my intention 
to comment on RFC 6257, which I considered to be a rather recent or 
"active" document. Maybe I should ask that my comments, particularly on 
the other RFCs, be better interpreted as questions (and critique) rather 
than criticism (language issue, mea culpa).

Yes, I am familiar with Kevin Fall's paper. It was obviously my 
expectation about RFC 4838 that was wrong, so...

I am aware that there are various implementations of the bundle 
protocol, even for resource-constrained devices. Still, we are seeing 
issues with the specification in our scenario, which (in part) was the 
intent of my posts on the other (non-security) RFCs. Of course, as I 
have been told that most of my arguments have been made before, please 
feel free to disregard the noise.

Your links are quite relevant to our work, I will definitely look into 
these projects! Thanks!

Michael

Am 19.06.2013 09:30, schrieb Joerg Ott:
> Hi Michael,
>
> first of all (as RG co-chair), especially with our impending work
> on a successor to the bundle protocol, your thorough review is
> highly appreciated).
>
> As Sebastian said, RFC 4838 has a certain purpose and is to be seen
> in the context of the DTNRG and specifically the bundle protocol
> (for which it provides the framework).
>
> Speaking as an individual:
>
> You are surely right in saying that these documents don't answer
> all the questions.  They provide a basis, upon which you have to fill
> in your scenario-specific detail details.  There actually do differ
> quite a bit
>
> For a general architectural discussion, Kevin Fall's 2003 SIGCOMM paper
> takes a broader viewpoint and provides an excellent overview.
>
> We have seen a lot of efforts on mobile  opportunistic communication.
> In fact, the DTN architecture and the bundle protocol are quite a good
> platform (you can argue about some of the security details) as we
> found.  We built systems for mobile ad-hoc  networking on top of RFC
> 5050 and the TCP convergence layer with our our neighbor discovery and
> routing mechanisms.  See e.g. http://floating-content.net/ and
> http://www.ict-scampi.eu/ (and maybe http://www.netlab.tkk.fi/~jo/dtn/)
>
> Jörg
>
> On 18.06.2013 18:39, Sebastian Schildt wrote:
>> Hi Michael,
>>
>>
>> maybe 4838 is a bit aged and does not reflect all the things people
>> have come up with, since. And yes, while it says "_DTN_ Architecture"
>> it is tied quite strongly to the BP. So maybe it isn"t 100% what it
>> says on the can, but writing a short/concise RFC for everything that
>> can be called a DTN would probably be impossible. Or, to put it into a
>> more positive perspective: Partly the intention for the BP WAS to be
>> something for "all kinds of" DTNs. Like TCP/IP it aims for
>> generality,  but this implies tradeoffs. (and functionality-wise BP
>> includes "more stuff" than IP, which makes this balance harder)
>>
>> However, some more concrete remarks:
>>
>> Am 18.06.2013 um 11:06 schrieb Michael Noisternig
>> <michael.noisternig@cased.de>:
>>
>>> All these aspects clearly influence the solution space, including
>>> whether an overlay with separate addressing (and routing) is needed
>>> or whether a DTN protocol be directly integrated at L3, whether
>>> interactivity between network nodes is feasible, how (key) management
>>> can be supported, how routing can be supported, etc. What I did find
>>> in the document instead was "a DTN architecture for the bundle
>>> overlay protocol". As such the document already makes the assumption
>>> that DTN networks consist of heterogeneous interconnected networks
>>> and that the bundle overlay protocol is the appropriate solution.
>>> However, homogeneous resource-constrained networks are unlikely to
>>> benefit from the bundle overlay protocol, even when compressed
>>> headers (CBHE) are used and the protocol is directly implemented at
>>> L3. As such
>>
>>
>> Ah, a good opportunity for a shameless plug! In fact we DO use the BP
>> as L3 protocol on Contiki based WSN nodes over IEEE 802.15.4. There
>> are two papers and a GIT to "prove it":
>>
>> Pöttner, W.-B.; Busching, F.; von Zengen, G.; Wolf, L., "Data
>> elevators: Applying the bundle protocol in Delay Tolerant Wireless
>> Sensor Networks," Mobile Adhoc and Sensor Systems (MASS), 2012 IEEE
>> 9th International Conference on , vol., no., pp.218,226, 8-11 Oct. 2012
>> http://www.ibr.cs.tu-bs.de/papers/poettner-mass2012.pdf
>>
>>
>> Georg von Zengen, Felix Büsching, Wolf-Bastian Pöttner and Lars Wolf:
>> An Overview of μDTN: Unifying DTNs and WSNs, in Proceedings of the
>> 11th GI/ITG KuVS Fachgespräch Drahtlose Sensornetze (FGSN), Darmstadt,
>> Germany, 2012
>> http://www.ibr.cs.tu-bs.de/papers/buesching-fgsn2012.pdf
>>
>> http://www.ibr.cs.tu-bs.de/projects/mudtn/
>>
>> While SDNVs and such propose a challenge to small nodes, it is doable
>> with reasonable efficiency. We are convinced this is a better solution
>> than for example 6LoPan for many application scenarios. Without
>> knowing exactly what you are planing YMMV.
>>
>>> (and in part because of the complexity of the bundle security solution),
>> You mean the Bundle Security Protocol? I am not very active in that
>> area, but my feeling is, most people in the community agree, that this
>> is still sub-optimal
>>
>>
>>
>>> 3.2 and 3.3:
>>> What wasn't really clear to me in both RFC 4838 and 5050 was the
>>> whole node-to-EID registration process. A node registers to an EID,
>>> and an application somehow gets associated/registered with a node
>>> (via some socket API?). (So there seem to be two separate
>>> registration processes.) Then if all applications connect to the same
>>> node (e.g., a daemon) how do the applications get multiplexed on the
>>> channel? Or is there a 1-1 relationship between applications and
>>> nodes? If an application selects the EID to register to how can we
>>> assure a unique "singleton" EID for each node? How do these EIDs get
>>> registered within the network?
>> In THEORY BP has a "an EID can be anything" concept: A node, many
>> nodes, one name amongst many for a node, an interest, a haiku...   in
>> PRACTICE, when using DTN2 or IBR-DTN implementations (and probably
>> others), it mostly comes back to the more mundane: An EID is a node
>> identifier, the path is used for multiplexing like Port numbers:
>> dtn://node1/myApp  -> Boring, but that is what is mostly  used.
>> "Colliding" EIDs may, or may not be a problem also depending on the
>> employed routing. 4838 or 5050 do not offer any solution for
>> generating unique EIDs (but putting some sort of Mac Address into an
>> EID is straight-forward)
>>
>>
>>>
>>> 3.3.2:
>>> Late binding is a nice concept, but of course it conflicts with
>>> routing under mobility where identities do not necessarily represent
>>> locations. How is this issue going to be resolved? I'm not sure
>>> leaving this as an implementation matter is the appropriate "solution".
>> Routing. A can of worms. Like in the WSN community, some "standard"
>> approaches exist that work so-so, often application specific solutions
>> seems to be the key. . Others might disagree, but it really depends
>> much on the application, with scheduled IPNs the one extreme and
>> completely undeterministic, opportunistic networks at the other.
>>>
>>> Related to this, can (or how can) DTN nodes from different networks
>>> (with different schemes) register to the same EID?
>> I am not sure if I understand this correctly, but different schemes,
>> imply it is a different EID (it may be the same node), i.e. ipn://23.1
>> is not the same EID as dtn://23.1
>>
>>
>>
>> Sebastian
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> dtn-interest@irtf.org
>> https://www.irtf.org/mailman/listinfo/dtn-interest
>>
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-interest