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
- Re: [dtn-interest] Comments on RFC 4838 Sebastian Schildt
- [dtn-interest] Comments on RFC 4838 Michael Noisternig
- Re: [dtn-interest] Comments on RFC 4838 Joerg Ott
- Re: [dtn-interest] Comments on RFC 4838 Caini Carlo
- Re: [dtn-interest] Comments on RFC 4838 Michael Noisternig
- Re: [dtn-interest] Comments on RFC 4838 Michael Noisternig
- Re: [dtn-interest] Comments on RFC 4838 Michael Noisternig
- Re: [dtn-interest] Comments on RFC 4838 Joerg Ott
- Re: [dtn-interest] Comments on RFC 4838 Burleigh, Scott C (313B)
- Re: [dtn-interest] Comments on RFC 4838 Michael Noisternig
- Re: [dtn-interest] Comments on RFC 4838 Burleigh, Scott C (313B)
- Re: [dtn-interest] Comments on RFC 4838 Michael Noisternig