Mobile Ad hoc Networks (MANET) Minutes Meeting : IETF70 Wed December 5th 9am Location : Westin/Salon 3 Chairs : Ian Chakeres ian.chakeres@gmail.com Joseph Macker joseph.macker@nrl.navy.mil Jabber : manet@jabber.ietf.org Audiocast: http://www.ietf.org/audio// URL : http://www.ietf.org/html.charters/manet-charter.html http://www.ianchak.com/manet http://tools.ietf.org/wg/manet/ Proceedings: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=70 Minutes : Jerome Haerri ========================================================= Meeting Summary Several WG documents have moved out of the WG and onto the IETF/IESG since the meeting in Chicago, and we hope to progress several more documents before Philadelphia. Please review and provide feedback on SMF, NHDP, OLSRv2, and DYMO now. http://tools.ietf.org/wg/manet/ During the meeting the SMF presentations identified several interesting challenges, and the solutions proposed in the Internet-Draft (I-D). I encourage everyone to review the document and slides from the meeting. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=70 There were three discussion related presentations during the meeting. The first was on temporary loops and preventive measures. There were some questions as to the reason for the looping in the scenarios presented and the implementation. Additional, discussion on both the implementation and the problem are needed before proceeding. The second was on using jitter for data forwarding in conjunction with SMF. The preliminary experimental results show that it may be helpful in reducing collisions. The experimental results also demonstrate that packet loss may reduce the ability to reliably deliver packets within a strict hop count. Additional experimental results and discussion are encouraged. Third the concept of a "MANET Identifier" was discussed. The microphone discussion demonstrated the wide variety of possible uses for a MANET Identifier. The next revision of the I-D will include a description of the behavior (for DYMO), and some simple use case scenarios will be discussed on-list. During the open microphone period at the end of the meeting, the issue of metrics for NHPD/OLSRv2 was brought up. Since the WG time was up, the discussion on this topic will need to be held on-list. Below are the detailed minutes: ========================================================= Administriva - Mailing list: manet@ietf.org - Presentations have been updated very recently. Please log on to download the latest version. - Scribe: Jerome Haerri (haerri@tm.uka.de) - Blue Sheets: Please sign your name on the blue sheets - State your name at the microphone when asking questions - IPR - RFC3979 ========================================================= Agenda bashing Speaker: Ian Chakeres Content: WG Progress o DYMO Discussion - draft-ietf-manet-dymo-11.txt o SMF Discussion - draft-ietf-manet-smf-06.txt o NRL SMF Implementation Update o MANET Neighborhood Discovery Protocol Discussion - draft-ietf-manet-nhdp-04.txt o OLSRv2 Discussion - draft-ietf-manet-olsrv2-04.txt o Loop Detection Discussion - draft-mase-manet-loopdetect-00.txt o Data Forwarding with Jitter in SMF o MANET IDentifier Discussion - draft-chakeres-manet-manetid-00.txt o Open Discussion, Related Work & Announcements - Metrics, other - draft-dean-manet-metriclv-00.txt - draft-dearlove-olsrv2-metrics-00.txt ========================================================= WG Progress Speaker: Ian Chakeres Content: - Manet WG status - IPR: attendees are kindly asked to speak up if they know/have IPR technologies - Brief update on all documents. See slides. @ IANA is in RFC editor @ Jitter: almost there, the WG has cleared the changes required from IESG @ packetBB/TimeTLV: an IETF last call will be issued by Ross shortly @ other documents (NHDP, OLSRv2, DYMO, SMF): received the comments. Will integrate them in the near future. The focus of the WG has been on the updates of the previous documents. - Document relationships Comments: Thomas Clausen: ManetID should be discussed at the very end in order to have enough time for debate Ian Chakeres: agreed ========================================================= DYMO Discussion - draft-ietf-manet-dymo-11.txt Speaker: Ian Chakeres Content: See slides @ Significant Changes: Link Metric: distance instead of hops size: 16 bits @ Minor Changes in routing information @ Some more precisions in the RREP section @ Next Step: * Reflects the changes in PacketBB in DYMO * Management + MIB documents * Basic Authentication * Generalized TTL Security Mechanism (GTSM): possibility to receive messages from other MANET routers... Comments: none ========================================================= SMF Discussion - draft-ietf-manet-smf-06.txt Speaker: Joe Macker Content: See slides @ Who read the latest version? * Less than 10 hands @ Cannot debate on the changes as only a few attendees read the recently updated ID @ The objective is an Experimental RFC * Encourage experimentation @ Major Changes from SMF -05 -> -06 * New sections, but also significant parts have been removed => only 1 more page * DPD delay has been added * CDS delay has been added * NHDP compliance added, yet NHDP is only optional @ Specific Changes * S-DPD changed to I-DPD: Identification-based Duplicate Packet Detection It mitigates sequence-based security * Lightweight Checksum: every ten bytes instead of all bytes improves the checksum efficiency * IPv6 processing part: Changes with help from Teco Boot * Relay Set updates: - Added a section in document to specify TLVs - Support of different kinds of CDS @ SMF security issues: * SMF Reliance on DPD can make it subject to DoS attacks * Low cost attacks: may stop traffic flows * spamming is not considered * Low cost attacks: - Pre-play attack: it spoofs a packet with a predictable DPD => the packet is considered as duplicate and discarded - solution: Cryptographically strong H-DPD (heavy), or an internal hash used in conjunction with I-DPD (lightweight) - Wormhole attack: Attacks flows, for example, by reducing the TTL - problematic for I-DPD and H-DPD with internal hash - possible solutions: - keep TTL/hop limit of forwarded packets with DPD table states - if a packet arrives with a TTL larger than the previous one, forward the packet and update the TTL in the table - It might temporarily generate duplicate forwarding. But this should be exceptional. Comments: Brian Adamson: Hash mode: using MD5 ? Joe Macker: Yes, but we are aware it is limited Brian Adamson: SMF can elect a different set of relays than NHDP ? Joe Macker: Yes, NHDP is only optional ========================================================= NRL SMF Implementation Update @ Speaker: Brian Adamson @ Content: See slides @ NRLSMF: improved changes. Still needs nrlolsrd (or other) if NHDP is required. Future version to include it. @ New features: Table-based I-DPD and added support for H-DPD - simulations showed that I-DPD + hash uses less resources than H-DPD @ Next Step ? - lightweight algorithm for internal hash... - security vs. complexity trade-off - implement the correction against the wormhole attack - support NHDP and multiple types of relay sets Comments: Joe Kopena: we use SMF for research and development: the new version is more readable small issue: Relay set should be included in the document, and very interested in the hashing addition, yet concerned by the CPU usage. We suggest not to over-specify the Hash function. Brian Adamson: True, a trade-off is required. Multiple-relay sets will be implemented in the future release Charles Perkins: Need to quantify the CPU drain Brian Adamson: We will collect data with specific metrics Charles Perkins: MD5: no CPU usage at all, but of course, there are better ones Brian Adamson: Right, more specifically for video streaming. Yet, we need to create a cryptographically strong hash to avoid attacks Charles Perkins: Have you already witnessed a wormhole attack in SMF ? Brian Adamson: no, but it might happen, and we need to be ready. DPD creates new vulnerabilities...need to solve them ! ========================================================= MANET Neighborhood Discovery Protocol Discussion - draft-ietf-manet-nhdp-04.txt Speaker: Thomas Clausen Content: See slides @ too busy with the updates of the other documents. Does not need a lot of updates @ Changes are not published yet, but has been identified and will be added to the new version of draft that will be published soon - Coherence with the updates in PacketBB + Jitter + TimeTLV - Identify: recently-used-own address - Removed: local interface block THEN_IF_TLV * replaced by: LOCAL_IF_TLV Comments: none ========================================================= OLSRv2 Discussion - draft-ietf-manet-olsrv2-05.txt Speaker: Thomas Clausen Content: See slides @ same comments as before regarding business @ updates: Coherence with the updates in PacketBB + Jitter + TimeTLV @ Identify: recently-used-own address - don't use it, don't pay for it @ Removed: local interface block THEN_IF_TLV - replaced by: LOCAL_IF_TLV @ Will Add: missing section on Set consistency (in ID-06) Comments: @ Ian Chakeres: The next revision is necessary @ Thomas Clausen: Yes, and also the discussion on OLSRv2 with metric as specified in the Christopher Dearlove draft Yet, OLSRv2 without metric support will be published soon @ Joe Macker: The metric document and work is orthogonal to this work. Need to create a metric discussion in order to gauge the complexity and progress @ Thomas Clausen: Yes, absolutely @ Justin Dean: We may also need to have something like ManetID... ========================================================= Loop Detection Discussion - draft-mase-manet-loopdetect-00.txt Speaker: Yasunori Owada Content: See slides @ Routing protocols are not loop free. There are temporary loops. Two types of loops: - mid-loop detection: - post-loop detection both need to be notified to the routing protocol. @ Key Features: - Loop detection and looped packet discarding - Routing independent - For now, we only discard a packet that loop Comments: @ Joe Macker: Used OLSRv2. Did you use NHDP ? @ Yasunori: Yes, we have an early version of NHDP @ Chris Dearlove: Do not agree with the results. There should not be any loop in static case in OLSRv2 @ Joe Macker: That is correct @ Ian Chakeres: In the figure, there are loops in static case only when you enable LLN. So, LLN generates loops even on static configuration @ Chris Dearlove: OK, but loop detection is not a major issue here @ Joe Macker: here..there is no mobility, but still loops: reduces the convergence time and increases the packet loss @ Thomas Clausen: Simulation Parameter: CBR streams and no congested network...Do you let the necessary time to converge before computing the loops ? It needs to converge before mobility alters the scenario, otherwise, any protocol has loops. Is there a long term persistent link looping issue ? @ Justin Dean: Indeed, and when you do not let the time to converge, it creates congestion due to loops, which in term creates congestion in traffic. @ Thomas Clausen: If we discard data information with LLN, we create loops. But this is because it is done wrong. The way that is done here is not the way it is suggested in the specification. @ Teco Boot: Even in static cases, loops exist, as random traffic influence other links (data traffic packets collides with control packets => the maintenance is then not correct, and loops are created). @ Joe Macker: Right, due to fading and other PHY layer issue, control packets that are supposed to be received might be lost. Yet, in this work, there should not be any loops (see configuration parameters) @ Teco Boot: Yes, but in real deployment, there are loops, and thus this work makes sense @ Yasunori Owada: OK for static. But with mobility, only loop detections can reach low loop generation in OLSRv2 with or without LLN @ Brian Adamson: When a loop occurs, it creates a congestion, which results in packet losses, which in turn creates new loops. It is a self feeding circle. We have a potential gain to remove loops. @ Justin Dean: Agree with Brian. But why discarding packets. Why not sending a packet back to where it came from when there is a loop. @ We could monitor the level of congestion from surge of traffic. Then set experiment from where the surge comes from. @ Thomas Clausen: Ok, loops are bad. This solution is indeed protocol independent. But the interaction with parts of the loops generated by LLN depends on the protocol. Moreover, does this problem come from a wrong specification (LLN), or not ? Is it important ? @ Charles Perkins: Rough statement: In a non-dynamic network, DSR for instance does not create loops. So, this work is not needed unless we see more loops. ========================================================= Data Forwarding with Jitter in SMF Speaker: Ronald in't Velt Content: see slides @ This work looks at the impact of MAC layer collisions on SMF goodput @ MAC layer collision => packet losses @ the capture effect reduces this issue @ adding jitter in data packets should also help - but the MANET jitter document only mentions control packet jitters. Comments: @ Thomas Clausen: Interesting work. Jitter ID was indeed only written for control traffic, as control traffic is sent periodically => we can easily evaluate the benefits @ Chris Dearlove: Delaying traffic may be very bad, depending on the traffic rate. Trade-off required @ Brian Adamson: If you constrains a bound on multicast traffic, a data-jitter could be adapted. @ Charles Perkins: Should we also introduce some reliability signaling? @ Justin Dean: I would like to see similar experiments when reduced relay sets are used. ========================================================= MANET IDentifier Discussion - draft-chakeres-manet-manetid-00.txt Speaker: Ian Chakeres Content: see slides @ Administration label routing @ Enable to restrict dissemination @ Related concepts: OSPF Area-ID / Instance-ID - packets are discarded if they do not match Comments: @ Justin Dean: Latest SMF includes an algorithm-TLV - Two TLV: one for area / one for the algorithm used @ Ian Chakeres: Should we identify the semantics ? @ Justin Dean: yes @ Chris Dearlove: It is also possible to have different protocols using NHDP and interacting... It could be included in the problem statement of the different document and not on a separate document @ Ian Chakeres: Well, separate issues, separate documents. But that is true that we might have to add this issue in related documents. I have concerns about this... @ Teco Boot: In SMF, there are different algorithms that do different things. We need to use algorithm TLVs => Compatibility issues ? - OLSRv2+SMF: what if both use NHDP ? - Two unicast protocols (DYMO+OLSRv2), what would be the implication of this ? * Autonomous domains administrated separately... Then we have tagging issue: what/how to tag ? Is this also the definition of what happens in the border of MANETs ? These issues are yet orthogonal to which kind of algorithm is used. => can we do this later (after the standardization of OLSRv2 and DYMO) ? @ unknown: Is it the extension in order to administer a network ? @ Joe Kopena: How to use that TLV ? conflicting TLVs with algo TLVs..in IPv4, within an administrative area, we can use different algorithms @ Ian Chakeres: Can the protocol make assumptions on the behavior in a region or not ? What are the real semantics ? @ Joe Kopena: Restricting TLVs only in address blocks ? @ Ian Chakeres: Ok, the semantics will be different if it is a packet TLV or a message TLV @ Justin Dean: Maybe we should use several TLVs, one for each behavior. For now (as an example): - SMF + NHDP using MPR - OLSR + NHDP (also using MPR) Same kind of message => There will be a conflict @ Chris Dearlove: It is not a problem, but a problem statement: authentication TLVs, permissive hooks... @ Charles Perkins: Is there any case that needs to be addressed before the RFC ? @ Ian Chakeres: That is exactly what and why we do it here... @ Charles Perkins: Hoping it is not required, as it is highly controversial => It will make us loose time @ Thomas Clausen: We should add permissive hooks in the protocol, but out of scope here @ Joe Macker: Different domains are different from different versions of a protocol. We jumped too far. @ Sue Harris: This is a major field that might have consequences on other ones out of MANETs. Besides, there are related works on that. @ Joe Macker: It is not our aim to solve this issue, but provide the means of doing it. @ Chris Dearlove: Sue, could you specify which are the documents we need to read ? Moreover in NHDP, we can have different relay sets using different metrics for instance. Thus, even different set even with same algorithm. It should also be addressed for interoperability. @ Emanuel Baccelli: Is there a solution for a node using different CDS ? Or nodes at different administrative levels or using different protocols ? @ Ian Chakeres: There seems there are a lot of semantics people that disagree. We should make a list of issues and discuss it @ Joe Macker: It is not a problem statement yet...it looks more like an architecture issue. @ Ian Chakeres: right, but if there is an identifier, it should be clear... @ Teco Boot: If we want to develop something we need a semantic => we need to define tags. What does it means if we need to put semantics in a network cloud ? @ Joe Macker: We need to define the administrative domain @ Thomas Clausen: This looks like two different discussions: 1) interactivity between isolated domains 2) interactivity in multi-protocol or multi-domain working in a same cloud I think 1) was the original goal. Let's go to the basic and define a problem statement. @ Sue: Definition of an administrative domain: single person, but could also have different routing domains The idea is good, but you need to clarify it. For example, BGP defines the policies ad the boundaries. In MANET, the separation is not that clear. ========================================================= Open Discussion, Related Work & Announcements Speaker: Ian Chakeres Content: @ We know have time to discuss related works... @ Metric(s) Discussion - draft-dean-manet-metriclv-00.txt - draft-dearlove-olsrv2-metrics-00.txt Comment: @ Charles Perkins: - PacketBB: Last revision: ordering of TLV ? - NHDP: issue of large packet size: compromise between functionalities and packet size. Yet, in NHDP, there is a significant increase in packet size. Need to specify the impact on the protocol of this increased packet size. We did some protocol work on reducing overhead. Increasing the packet size does impact performance. It is not really when you have more packets, but when you have larger packets that need to be sent. There is a drop in performance. @ Teco Boot: For the MANET WG, do we need to look at metrics ? In this version ? @ Justin Dean: Metric TLV has not been updated. A new version will be published soon @ Teco Boot: Need to discuss the two drafts during this week and see if we need to add it to the WG @ Thomas Clausen: right, but we also need to discuss if we can do it, and who would be in charge of it @ Sato Yioshi: A work on Metrics is important, but it would be more important to keep the pace in the standardization, as it is even more important. Besides, defining metrics is very hard @ Joe Macker: Need a metric container in this specification. We might not know what to transmit, but at least how to transmit it. @ Chris Dearlove: Adding metrics could bring compatibility issues with the current documents. It could also break the different protocols. What to transmit is someone else's problem. How to transmit it is our problem. @ Justin Dean: Just a remark: Metric TLV is just a container... @ Charles Perkins: Important subject. Needs to be addressed. Besides, should be use metrics of 8/16/32 bits ? @ Teco Boot: There does not seem to be much progress on metrics in OLSRv2. Are we doing the right thing ? @ Ian Chakeres: I suggest we discuss this topic during this week in order to isolate the problems. =========================================================