Mobile Ad hoc Networks (MANET) Agenda Meeting : IETF 77 Tuesday March 23rd 2010 Time : 1740-1940 Location : California C Chairs : Ian Chakeres ian.chakeres@gmail.com Joseph Macker joseph.macker@nrl.navy.mil Jabber : manet@jabber.ietf.org Audiocast: http://videolab.uoregon.edu/events/ietf/ URLs : http://www.ietf.org/html.charters/manet-charter.html http://tools.ietf.org/wg/manet/ http://www.ianchak.com/manet https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=77 ========================================================= AGENDA o Administriva - Mailing list: manet@ietf.org - Scribes: Justin Dean - Minutes taker: Ulrich Herberg and Thomas Clausen - Blue Sheets - IPR - RFC3979 o Agenda bashing o WG Status (Ian Chakeres) o NHDP, OLSRv2 Discussion (Thomas Clausen) - draft-ietf-manet-nhdp-11.txt - draft-ietf-manet-olsrv2-10.txt o SMF Discussion (Joe Macker) - draft-ietf-manet-smf-10.txt o DYMO Discussion (Ian Chakeres) - draft-ietf-manet-dymo-18.txt o MIBs Discussion - NHDP MIB - DYMO MIB - SMF MIB - OLSR MIB o REPORT-MIB Discussion - draft-cole-manet-report-mib-02.txt o MANET Cryptographical Signature TLV Definition - PacketBB Security - NHDP Security - NHDP Threats o Open Microphone - Discussion, Related Work & Announcements - ChaMeLeon - ETX with OLSRv2 - Protocol extensions ========================================================= Minutes Ian Chakeres: walks through agenda, note-well / IPR reminder, presents document status (NHDP sent to IESG for IETF last call, AD review, DYMO in WG last call until April 8, SMF WG LC ended, no major revisions, decision kept on hold whether to issue another WG LC) Joe Macker: when reviewing SMF, keep in mind it's experimental, still has some issues that need to be addressed (other documents are Standards Track) Ian Chakeres: no major update to OLSRv2, waiting for integration of draft-dearlove-olsrv2-metrics into OLSRv2, concentrating on NHDP, MIB documents have been reviewed, considering two more documents for WG IDs (REPORT MIB, PacketBB-sec), we should talk about extensions as private drafts Thomas Clausen: presents NHDP history (became independent draft in 2006, first WG LC in 2008, 2nd WG LC in Aug 2009, Feb 2010 publication request + IETF LC finished, reviews from GEN-ART, SEC-DIR, RTG-DIR & IANA incorporated into version -12 no major issues in the doc, fixed nits, next steps: AD review and go-ahead, IESG review (waiting for that now) state-machine ID not yet done, to be released soon. Presentation of OLSRv2/metrics updates: none to the specification, intended to release a new update to the OLSRv2 ID this week with small updates and fold-in of metrics draft announcement of next OLSR(v2) interop in Philadelphia, around mid-September 2010. Joe Macker: presents SMF updates minor revision, better alignment with OLSRv2 in appendix, waiting for NHDP being published Thomas Clausen: I agree it is time to consider SMF publication. Asks for time to review. Joe Macker: agree, we could issue another WG LC Thomas: some dependencies to NHDP; WG LC should not coincide with DYMO WG LC Joe Macker: reminder of experimental status, please read document, send comments Ian Chakeres: WG LC will probably end two weeks after DYMO LC to give enough time for reviews Ian Chakeres: presents DYMO updates, update of diagrams and better integration of packetbb, left DYMO identifier in documents since it has not been migrated into NHDP, received some good feedback, encourage to give more feedback, plan to revision of Security Considerations section and 5.3.2 and 5.3.3 (for improved readability), no major changes planned possible extensions could be explored (multiple paths, local repair, using precursor lists, dynamic timers,...) Thomas Clausen: What implementations of DYMO exist? Ian Chak: I know of several implementations, however not sure whether they are up-to-date. Thomas Clausen: Could you solicit for implementations in one of the subsequent IETFs? Ian Chakeres: yes Joe Macker: since WG LC for DYMO, there is standardized way to reference downward and normative references, may want to add that to the document, since NHDP is normative reference Ian Chakeres: no, not a normative reference. Joe Macker: okay, but I will have that problem for SMF. We need to add a note in the references section that this is a downward normative references Thomas Clausen: what is a down reference? Joe Macker: used when an I-D is cited as normative reference in a document in RFC editor Thomas Clausen: what usually happens is that the document will be held in RFC editor, until normative reference is published as well. Down reference usually means a Standard Tracks document referencing an Informational document as normative reference. Joe Macker: okay. There is a way of pointing that out to the reviewers. Ulrich Herberg - presents MIBs Mainly update of NHDP MIB. Notifications, inspired by OSPF-MIB for link up/down status notifications. Notification for unparsable message probably needs to be changed as in OSPF it is for a single message, but in the NHDP-MIB we need that counter for maybe handling multiple messages that cannot be parsed. Security considerations added - needs reviews. OLSRv2-MIB No update, awaiting NHDP-MIB and OLSRv2-MIB stabilization. Outstanding issues / path forward. Now, there is reference to REPORT mib, need to ensure that it is correct. Looking for implementers Hope for WGLC of NHDP-MIB before the next IETF, then proceed with OLSRv2-MIB. Joe Macker: do you plan on start with OLSRv2 MIB before or after WGLC on NHDP MIB? Ulrich Herberg: Probably want to do NHDP first Henning Rogge from Jabber: any work on small-footprint MIB/SNMP libs? Ulrich Herberg: Not that I know. Henning Rogge: And NetSNMP? Ulrich Herberg: Not that I know. Joe Macker: We did have some threads on Jabber at the last meeting on the appropriateness of SNMP for this type of applications. Ulrich Herberg: We may want to think of additional ways of monitoring and controlling this in a more light-weight manner, perhaps managing the whole MANET not the individual router. Thomas Clausen: There were discussions in ROLL about management of sensor networks. There has not been progress with regards to this topic. We should work on this, something other than big routers. Ulrich Herberg: That reflects my knowledge as well. Would be interesting to look at, and I tried to launch emails to this effect last meeting. Robert Cole: no major updates on DYMO-/SMF-MIB DYMO-MIB almost done, waiting for DYMO ID, SMF pretty good shape question: SMF is Experimental; does that mean that SMF-MIB has to be experimental too? Joe Macker: no idea, but probably yes. I will figure it out. Joe Macker: can we use FIB-MIB for MANET? Robert Cole: we thought about referencing the FIB-MIB from DYMO, last update to the FIB-MIB 1.5 years ago, was not clear how to extend FIB-MIB, MIB-doctors did not know either, so I implemented forwarding table directly into DYMO-MIB, could be used in OLSRv2-MIB as well if FIB-MIB was extensible. Joe Macker: good to know, we need to address this. Robert Cole: REPORT MIB updates front-end to MIB objects on MANET router, configure offline-recording, report generation, collection of statistics fair amount of revisions, feel that it is complete updates: included raw data collection (report history group), based on requirements of NHDP-MIB by Ulrich, rename reportUsrHistoryGroup to reportSampledGroup, modified structure: statistical group (collect statistics on change of counter) sample group: e.g. collect counter in fixed time intervals, historical group: track changes in counters. work items: proposed set of notifications, Security Consideration section conformance section is large: 8 or 9 conformance cases, to be flexible should it become WG item? Ian Chakeres: I have reviewed the document, but we should ask for it on the list Thomas Clausen: reviewed it too, should become WG doc Ulrich Herberg: should become WG doc Teco Boot: status of it? experimental or standards tracks? Robert Cole: no thought yet Teco Boot: SMF using it? Joe Macker: SMF MIB is independent, defines some methods for reporting Robert Cole: REPORT MIB is extracted from RMON RFC2021, because was not possible to reference it without copying it. Ulrich Herberg presents NHDP & OLSRv2 security Individual drafts (x3) - more to come. PacketBB sec - the most stable of those currently submitted. Intended to be applicable whenever RFC5444 is used. NHDP-sec describes how to verify and sign messages, use TLV from packetbb-sec and signing a hash-function, taking some things (zeroing hop-limit/count) and some border-cases. Update to PacketBB-sec - mostly editorial, biggest change was to add the ability to associate signatures to also addresses, not just packets and messages. This was motivated by the desire to provide fine-grained security, verifying that both ends of an advertised link are trusted participants. Present "Fine Grained Security" in NHDP/OLSRv2 - question if trust-model (Advertiser-is-trusted) is sufficient, or if both-ends-verified is needed. Will update this very soon. Comes at a high cost, not suitable for all requirements and so therefore possibly "optional", this discussion will be included in next revision Vulnerability analysis (sec-threats NHDP/OLSRv2) - intended to be informational. Major update expected, analyzed these in much more detail in a research report, and will go through that briefly here, but expect update to the I-D(s). Taxonomy: LS protocols require certain things for proper operation (accurate topology, reflecting the effective topology, and that the network converges). OLSRv2 can be broken by violating either of these. Joe Macker: There is an NHDP-sec-threats draft out. some of this is a combination of NHDP and OLSRv2, how do you consider keeping this separate in I-Ds? Thomas Clausen: Important to factor out the issues of NHDP from OLSRv2. Not everyone will be using OLSRv2 but may be using NHDP. Joe Macker: I think we can pull that off. Exemplifies flooding-disruption (MPR) by an example (slide 8) - essentially, it is "easy" for a malicious router to be a "preferred candidate" for being selected as MPR (Willingness or spoof link to non-existing router). If malicious router "behaves correctly" wrt. flooding, then this is not a problem - however, in the case where it does not, it may inhibit TC message diffusion and thus therefore disrupt the network. Similar example for topology map acquisition disruption, for disrupting flooding. Joe Macker: suggests looking at the SMF document, and take on some forwarding/relay attacks, possibly discuss with Brian Adamson. Radio jamming attacks, surprising perhaps as it is a "lower-layer" than L3. May affect reception of HELLO/TCs, but not necessarily transmission. Hence, a "jammed" router may transmit correct HELLOs, received by others. NHDP (and thus OLSRv2) resilient to this by detecting uni-directional links. Hop-limit attacks - a "malicious router" may "purge" forwards by other routers through relaying TCs "first" with a 0 or 1 hop-limit (not forward, purge other forwards). Similar attack presented for validity-times (especially when we have fish-eye or similar advanced TimeTLV hop-dependent timer settings. Effective Topology discussion - wormholes and incorrect forwarding/replay-attacks is another class of attacks; the gravity depends on the nature and characteristics of the wormhole (does the wormhole forward, or not, data-traffic? If so, no problem, it's just a "soft link". If not, then it is a problem.) Integration with metrics draft: if the metrics for the link are misrepresented (i.e. a long soft-link with a small metric) may wreck the network connectivity performance, whereas if the links are correctly represented cost-wise, this will not be a problem. Discussing the timing and sequence number attacks (essentially, DoS attacks) also on the effective topology. Indirect jamming: trick a third-party legitimate router to cause the jamming, rather than the malicious router itself. Example: a malicious router forces MPR-set recalculation by advertising link as alternatingly SYM and LOST + HELLO message generation, possibly triggered (HELLO/TC) - although bounded by the MIN_INTERVAL. It is, as such, not possible to trick a router to send "infinitely frequent" messages, but still cause increased message emission frequency to be MIN_INTERVAL. Another, similar, attack is alternating MPR-set-selection, triggering TC message emissions. Inconsistent topology due to identity spoofing in NHDP: can disrupt traffic transiting the "attacked router". Can also be used in the LS advertisement. Slide 18. Routing loops - illustrates how link spoofing in TC messages can cause loops (albeit local). Overview of this report - will be integrated into the various sec-threats drafts, both for NHDP and OLSRv2, very soon. Ian Chakeres: have you spoken with the security director? Thomas Clausen: we should get security adviser to help with the document. Joe Macker: Because we are wireless there are certain attacks which are easier to do. We should illustrate which attacks may be easier due to the wireless nature. Thomas Clausen: Spoken to SEC ADs and SEC-DIR reviewers, as part of the security review of NHDP and 5444. Not this analysis in particular. As I understand it, sec-routing WG has very fixed objectives, but it might be beneficial to understand if there is interest from that working group to "help us out". Arvind Ramrekha: Presentation of CML Hybrid approach for increasing efficiency (delay, jitter), for emergency situations phases: r (reactive), o (transition between r and p phase), p (proactive) Henning Rogge: I do not think that emergency MANETs are different than MANETs Arvind Ramrekha: agree, but considering context: more obstacles, mobility, constraints on battery Justin Dean: instead of using the term Emergency MANET, list different criteria, specify what you are trying to do Joe Macker: second that. I was confused about the definition Thomas Clausen: is the aim of CML to provide energy-efficient routing? is battery preservation main goal of this I-D? Arvind Ramrekha: no, main objective is to improve jitter, delay for (multimedia) data traffic Messages Types: CP (change phase), HCReq (hop count request), HCRep (hop count reply, for estimating size of network in reactive phase) overview of the algorithm: start in p phase (proactive) uses OLSR, as soon as receiving e.g. TC message that may increase network size, contact monitor function of adaptive module checking for network size, using a threshold (based on simulation and experiment, as well as mathematical model). Thomas Clausen: back 2001,2002 lots of studies done for applicability space for when using proactive/reactive, well understood. It is less understood how network size influences performance when using either proactive or reactive routing protocol. Strongly depends on traffic (number of communicating pairs). I think that looking network size as threshold is inappropriate. Arvind Ramrekha: when fixing traffic amount and duration of connection, depends only on number of nodes Thomas Clausen: no you are not. It then depends where the pairs of communication devices are, and the topology. It is important to be explicit about assumptions/conditions before talking about protocol. Arvind Ramrekha: yes. we will try to publish in an academic publication. Teco Boot: whole network switching between reactive/proactive or only parts of it? Arvind Ramrekha: we start with proactive network and switch whole network Joe Macker: model is too simplistic, e.g. in analytical model you take average density, but not generalizable in reality Henning Rogge: using hop-count^2 for network size may overestimate network size, and the mathematical model would break down in reactive mode Arvind Ramrekha: not exactly the square of hop-count, but a function of it with all parameters. So, network size is not overestimated too much. Thomas Clausen: you answered to Teco that all routers are in either phase. Switching means change of internal state, convergence time, etc. Lots of operations to establish paths between pairs necessary. I hope that the switch operation is rare. Maybe so rare that it makes more sense to plan the network with the right routing protocol from the beginning. Arvind Ramrekha: In our scenarios, network remains stable. When network size changes, it should operate more efficient for that particular time. Thomas Clausen: what is stable? Arvind Ramrekha: Having a particular routing protocol operating for a long time, For preventing oscillation: oscillation size and oscillation frequency parameters introduced. We use timer to have minimum time before allowing oscillation, plus lower and upper bound for network size to determine when to switch. features: improve efficiency of multi-media data and jitter, save battery power, plan to define thresholds based on mathematical model, further techniques to reduce oscillation, implementing OLSRv2/DYMO Thomas Clausen: how does switching from one protocol to other (with costs) provide performance improvements. Within each protocol there are ways to improve protocols by tuning parameters in order to retain battery capacity. Arvind Ramrekha: We aim to save battery power Thomas Clausen: studying this in a mathematical model may not reflect in a real network. May not be the right approach. Using unit-disc model may not reflect reality. Disconnect between theory and practice. Joe Macker: Continue discussion on list Justin Dean: Concern about transition period (how long it takes). Would like to see more how that happens/ behavior. Joe Macker: I do not get the motivation switching from one protocol to the other (given that there are protocol parameters within each protocol that could be adapted). Could be better proven. Hybrid protocols are possibly very good when using the right constraints. Charlie Perkins: For example, when using proactive protocol and having too much signaling overhead, could be a motivation to switch to reactive protocol. Joe Macker: Or variance of proactive protocol with less frequent updates. There are different ways Teco Boot: Or using timers. This is an attempt to improve protocol, we should encourage this. Joe Macker: We had been chartered on such work, but unchartered it because it was complex. Difficult to figure out when it's optimal. Arvind Ramrekha: Question: is there interest in having an adaptive module for OLSRv2/DYMO instead of hybrid approach? Joe Macker: Any implementation is contribution, whether it should be chartered is up to the WG to decide. Thomas Clausen: DYMO/ADOV/OLSR/OLSRv2 are adaptive protocols in different way. In order to adapt new work we need to justify that these protocols are not sufficiently adaptive (outside mathematical models). Easy to show simulation results that a protocol better than other for a particular scenario, but scenario may not be realistic. Christopher Dearlove: we are close to standardization of what we are doing. Don't think this is the approach we want to do. Yes: hybrid protocol, but not CML. Arvind Ramrekha: question: is there a need for new charter for emergency MANET? Joe Macker: not sufficient evidence that this is different to what we are doing / want to finish chartered items. Once we have done that, we can consider rechartering. If you want to implement the protocol and present results, please do so. Emmanuel Baccelli: ETX draft presentation. deployment in Funkfeuer / Freifunk community MANETs, draft shows their experience with ETX since 2004, updated to OLSRv2 next step: harmonize it with draft-dearlove-metrics. Extracting parts to get non-symmetric ETX? Christopher Dearlove: have not yet reviewed ETX-draft. ETX is more than a metric, but a protocol (own signaling). But that is good thing, NHDP/OLSRv2 allows to extend it. Signaling exchange must be specified, in particular when a metric is needed by OLSRv2, but not yet available (e.g. use maximum value in that case) Emmanuel Baccelli: yes, already starting the discussion Henning Rogge: olsrd-ETX is used by the red cross in their camp in Haiti, as an example. Teco Boot: Worried about compatibility with metrics. If new routing metric should be used in a MANET, it's not backwards compatible. I suggest to first start using dimensionless metrics in OLSRv2. ROLL have a similar draft about ETX. We want to define metrics on top of OLSRv2 (based on only very experimental experience of ETX with OLSR). Propose to have two drafts, one describing the lessons learned, and another draft for specification. Emmanuel Baccelli: agree. This is only a first step. I-D documents experience of ETX for 6 years, upgraded to OLSRv2. How to standardize ETX in OLSRv2 is another question to be worked on by the WG. Christopher Dearlove: If ETX is a protocol and not just a metric, this is an extension to OLSRv2. Concerning the compatibility issue mentioned by Teco, a network will be fragmented when using different metrics. Incompatibility is that they may not be able to talk to each other, but it will not be incompatible in the sense that everything goes wrong (e.g. looping). Thomas Clausen: Answer to Teco. Intent is that OLSRv2 I-D will contain dimensionless metrics. There are ways of recognizing which metric is used. This draft does three things: 1. documenting experience 2. proposing protocol negotiating *some* metrics value for a given pair of devices 3. Reservation of code point for use by OLSRv2-I-D. Proposal to the ETX-draft authors: make those three things explicit. Teco Boot: We don't need protocol aspect of ETX-draft. It's just a metric for measuring link quality and exchanging them. Many metrics can be thought of (RSSI, ETT), in a dimensionless way. Priority is looking for a better metrics than hop-counts, not a new protocol. Emmanuel Baccelli: I don't understand the difference between the protocol part and the measurement part that has been mentioned by Teco. Teco Boot: Let's agree that it is wrong to specify the protocol part in the I-D, it should be specified in another draft providing the use of ETX using as a dimensionless metric. Joe Macker: Could it be more generalizable than as a cost metric? Teco Boot: We could then remove the protocol part. In the same MANET, some routers can use RSSI and others ETX. Outcome is simply using dimensionless metric.