Minutes of the DTNRG ==================== Thursday, 2013-08-01 The DTN Research Group met once at the 87th IETF. The meeting was attended by some 30 people. The meeting was chaired by Kevin Fall, Stephen Farrell, and Joerg Ott. Notes by Elwyn Davies and Ronald in 't Velt 1. Intro / agenda bash (Chairs) =============================== The meeting is structured into two blocks: present work items and issues (1-4) and forward-looking work (potentially future items) (5-8). No modifications to the agenda. 2. RG Status (Chairs) ===================== The chairs briefly reviewed the research group status and the progress of the individual documents. The CBHE registries, datagram and TCP convergence layers are close to completion. A number of other drafts exists, including one active RG document: draft-irtf-dtnrg-sbsp-00. Some drafts, albeit important, have expired. For example, neighbor discovery is an important problem to solve. The chairs asked who wants to "own" neigbour discovery draft? There're several drafts and then there are all sorts of undocumented implementations e.g. in DTN2. The new routing framework now underway will at some point interact with / influence neighbor discovery. Vint Cerf noted that we have to distinguish between opportunistic discovery and other cases (predicted contacts). The application framework is sleeping, but it might be reawakened. The bundle protocol query draft (-bpq-00) recently expired and should be revised. Kevin Fall noted that, give the close relation with ICN, both query and "push" are needed. There is further feedback from various implementations. Scott Burleigh noted that the bundle-in-bundle encapsulation draft is not on this list, because no "dtnrg" in draft title, should be ready. Jörg Ott noted that there is even an implementation in IBR-DTN. The various drafts related to coding will be discussed later. 3. BSP Discussion (Birrane) =========================== Edward Birrane presented the slides on streamlining the bundle security protocol. The presentations starts with an overview of RFC 6257 and discusses the diverse lessons learned from the implementation. See the slides. The presentation is highly interactive with a lively discussion summarized below: Slide 5: bundle src/dst versus security src/dst, need to go through sec. dst before bundle dst. The sec src/dest concept ties up routing and security. May be better to use an encapsulation mechanism. Kevin Fall: An alternative might be a 'loose anycast route'.. another case is custodian story Ed: 'A definite maybe'. Would it get coupled with security? Kevin Fall: Order may not be important... could get destination to send things back to security destination first.. useful to deal with various problems... tunnel is a mechanism.. is it the right thing to solve the problem Jörg Ott: Some kind of a service route. Scott Burleigh: Maybe a disservice to concentrate on tunnels as solution. A tunnel is just a mechanism, not the only way to solve the problem, remove this from the security spec. and deal with it elsewhere. Kevin Fall: have to deal in several place with chunks of bits that have to have things done to them Stephen Farrell: the solution for sec src/dest has turned out to be horrible.. should be taken into account Kevin Fall: group need to think about problem for the future Ed: Will try to answer this in a couple of slides The presentation continues after discussion, slide "major lessons learned from RFC6257"): decouple routing and security functions. Should increase support for non-payload integrity: Stephen Farrell: Could argue that what is being suggested (encapsulation) *more tightly* couples rtg and sec Support for non-payload integrity Elwyn Davies: Is anything being done to ensure that extension blocks haven't disappeared (or been added) along the waythere is no real way to ensure that at the end you have. the same set of extension blocks as at the beginning. If the security block is removed there is no indication that it ever was there. Stephen Farrell: I am worrying about nodes that are less capable. Is there an implicit assumption here that bundles travel through fairly capable nodes (e.g. not short on storage, processing power)? Ed: Not explicitly Scott Burleigh: only the nodes that deal with security need to be more capable. Stephen Farrell: Remembers that the idea was that sec dest could be used to handle doing all the heavy duty sec stuff before it gets into a crappy part of the network Ed/Scott Burleigh: Not an implicit assumption that there is heavy duty capablity at the end points.. encapsulation could potentially handle this also Stephen Farrell: Not totally convinced Difficulties may be that you want to send things like keys to end nodes. Kevin Fall : May be an operational issue to decide how/where to send bundles Ed/Scott Burleigh: This work is more about planning a new toolbox rather than identifying all use cases Slide "proposed changes": recommends "toolkit" approach. Jörg Ott: do you propose functional additions or are you just re-arranging existing components? Edward: also adding. Terminolgy discussion: Kevin Fall: Suggests could further generalize 'Security-Service' to general 'Service' proposal Ed: A security operation MAY NOT be applied more than once in a bundle.. might define a a multi-integrity ciphersuite to deal with cases where you want multiple signatures Kevin Fall: What about recursive operations as a possibility? Ed: Not seen general recursive operation.. generally domain specific. Stephen Farrell: Wonders about realizability of a multi-integrity ciphersuite at receiver Jörg Ott/Ed: Wonder about gateways... discussion of block encapsulation vs bundle encapsulation Stephen Fall/Ed/Scott Burleigh/Kevin Fall: Two discussions going on: (1) How to make a simple sec soln out of mess we have at the moment (2) How the previous mechanism went wrong and how you make it better. Abtract security block: 3 security block types instead of current 4 Specific security operation may not be applied more than once in a bundle. Stpehen Farrell suggests using another name instead of "security target". Security target: Discussion of how to synthesize a block identifer.. abusing the EID reference may cause major problems for code (SF) Vint Cerf: was hoping that each security block could be handled independently Scott Burleigh: Let's not go down the track of having multiple payload blocks .. because of fragmentation. Kevin Fall : Fragmentation around network coding get interesting Stephen Farrell: Might want to have some indicator of highest number used Block Types: Kevin Fall: Is there anything special about the sec extension blocks? Scott Burleigh: No .. they were always just ordinary extension blocks Ed: Some constraints apply Conanicalization: Stephen Farrell: Issue with forbidding applying integrity and confidentiality to fragments.. stops you adding a digital signature to every bundle that goes through. Ed/Scott Burleigh: Encapsulation might still be the right answer. Stephen Farrell: Was reason why fragmentation occurred considered? Encapsulation might make it worse. Ed: Refuses to answer question. Introduces philosophy... turns 2nd class objects into first class objects 4. Collection of desired small changes (All) ============================================ The time slot for the previous item ran over. It seemed worthwhile continuing the discussion. The chairs checked with the group. Nobody was against continuing in this slot. As a result, this item was dropped from the agenda. 5. Erasure Coding Approach (Hennessy) ===================================== Angela Hennesy presented the draft (expired) on erasure coding. The idea is adding reliability in case of fragmentation / short contact times. Kevin Fall: There was past RMT work, FLUTE, but there are novel aspect here. Angela: The Re-encoding is new.. might wish to stick with terminology even if different froom FLUTE as find it helpful Architectural Issues slide: encode at application layer or in the BPA? - If BPA, re-encoding possible - If done as a convergence layer, then only good for one hop. Jörg Ott/Scott Burleigh: Might need a secondary identification to add to EID Kevin Fall: This ties in with security discussion Vint Cerf: It is a lot simpler to do this at the application layer. Doing it at the BPA could lead to conflicts between authentication, integrity and erasure coding Angela: did think about security (.... missed) Jörg Ott: interaction with queries would be interesting Scott Burleigh: Thinks doing this as a convergence layer approach might be good. Kevin Fall: Disagrees. Because of collecting information from lots of different places. Kevin Fall: There are some problems with terminology in the drafts. Needs some work to synchronize terminology with other frameworks. Angela: can address this. Frank Fitzek: We have something similar, testbed with actual moving nodes, works perfectly 6. ICN and DTN: NetInf over DTN (Davies) ======================================== Presentation given by Elwyn Davies. This is used in the NetInf ICN protocol, SAIL project. The BPQ block is used to do NetInf over BP. Dirk Kutscher: one use case would be bridging disconnected well-provisioned ICN sub networks through DTN 7. Generic opportunistic routing framework (Lindgren) ===================================================== Anders Lindgren presented GORF. He observed that there are lots of research papers on routing, but only 2 so far specified in IRTF (PRoPHET, dLife). He hopes that others will try to implement their favourite routing protocol in this framework. Vint Cerf: General concern with this type of frameworks is that they may constrain the sort of routing protocols that can be implemented within them. Anders: mainly aimed at opportunistic routing. Jörg Ott: Consider routing protocols where you use long range, low-rate radio to announce presence and a shorter range, higher rate radio for the actual communication. Vint: Do such frameworks constrain sorts of protocols/topologies? Ellyn Davies /Anders/Jörg Ott: Potentially nice to know if nodes could use other sort of communication when a link (=contact) happens. Stephen Farrell: Could you use it with Contact Graph Routing? Anders: Good to try. Scott Burleigh: It would probably be overkill for CGR (also problematic for unidirectional links). Would be useful to combine CGR with opportunistic Vint Cerf: Isn't the forwarding table where all the info is combined? Edward Birrane: You may not have a single routing algorithm for the whole of the network (space +...(other subnets)). We have done some work with combinations of CGR and probabalistic routing. Interesting to deal with this in a two layer system. 8. Web-friendly DTN protocols (Farrell) (if time permits) ========================================================= Time did not permit, so this item was dropped from the agenda.