ROLL Working Group Meeting IETF-76 Agenda Bash =========== DC: Note well, IPR requirements DC: brief status; bullk of time coming up to date with huge RPL activity. DC: Agenda bash - Status RPL Routing Metrics Security Framework Planning - here to Anaheim (actually Pasadena) DC: David will channel JP who is not here DC: Update At Stockholm, family of candidate proposals, including Hydro-DT, others Took stakeholders & formed a design team --did not take the union Need an MVP - minimum viable protocol To meet constraints, simplicity is important DT - lots of work, weekly meetings (let by Tim - who is not here) 2nd draft and DT was resolved before Geneva Authors team formed, broader set of authoers Interim meeting with author team in Geneva in September Growth to -03, which was very "feature rich" 04 is significantly smaller than 03 - please to report Metrics draft is co-evolving Email reflector and authors list is very active; almost impossible to keep up Charter review Two documents are RFCs - RFC5548/RFC5678 other requirements docs are on track 3 primary documents Roll Charter Move the security framework document and arch document from yellow to orange (becoming time critical) Arch document could not precede routing work On schedule, but a tight schedule to move the ROLL routing protocol to ready to forward to IESG in February Other work that needs to be stimulated in work on MIBs RPL IPv6 Routing Protocol for Low Power and Lossy Networks ========================================================== draft-ietf-roll-rpl-04 Jonathan Hui, Authors Team JH: Review RPL to get everyone grounded Assumption - most traffic flows through a few nodes many to one / one to many baseline requirements Given that, build a DAG rooted at these nodes Up - towards the root Down - away from the root Use the DAG to detect & avoid loops Side benefit - allow point to point via up* down* Want simple mechanism to avoid count to infinity Definitions ----------- Instance - defines the optimization objective when forming paths towards roots Link properties (reliability, latency) node properties (powerer, not) Scope: Entire RPL network one or more disjoint Destination Oriented DAGS - DODAGs RPL creates the DAGS DODAG - defines a single root "destination oriented" DAG within an instance Union of DODAGs is the DAG for an instance can have two groups that advertise the same DAG id no concept of a DODAG across multiple instances Iteration - uses sequence numbers to create time "epics" Node Rank based on objective function; distance from root scope: within a DODAG Objective Function: identifies metrics, constaints and objectives Objective Code Point: identified to objective function Emmananuel Baccelli Question: I thought there was a consensus toward a single dag per instance? Are we back to multiple DAGs JH: only specify operation of a node for one instance at a time but an instance can have multiple DOGAGs Pascal: a DAG is an instance (basically no) DC: would be wonderful to simplify, simplifies some things, makes other things harder Jonathan's presentation covers the document as it stands in -03 JH: DAG Construction Distance Vector advertise path cost to root choose parents that minimize cost care to avoid loops and count-to-infinity Assign every node a Rank (strictly decreasing toward the root) Route Construction DAG is not forwarding topology, its a routing topology to help select what you put in forwarding table typically DAG parents Up Routes Via parents toward roots. Typically default route Down Routes move toward nodes of increasing Rank How do you know? Destination Advertisement that propagates upward either be record routes or non-record routes nodes have either no state, or enough to maintain down routes Forwarding Rules All routes: up*down* along DODAG When you go up, forward to a lower Rank node where possible may forward to a sibling if no lower rank exists (sibling -> equal rank node) When you go down, follow based on down routes Metric vs Rank Metric used to achive an optimization goal Rank - Establishes position within establishes topological constraint to avoid or detect loops course granularity allows siblings common language if we want to utilitize different OCP's in a DAG was an issue where people said you could utilize differnt OCP's Comment from Jabber: thought we were calling that cousin, not sibling JH: yes, understand that (just talking about draft 04 DC: for clarification -> OCP is bound to instance (collection of DAGs) JH: yes Protocol Mechanisms (draft 03 vs 04) Draft 03 was too complex, wanted to simplify. Major goal of 04 draft 03 to 04 Remove binding between RPL and IPv6 ND Removed detach/float/reattach Remove timers Conveyance 03 - put bits inside IPv6 ND options utilized router solicitation, RA's, NA's Feedback was that this was confusing and not appropriate 04 - RPL is self contained use ICMPv6 Code to identit RPL DIS: DAG Information Soli DIO: DAO: Loop Avoidance 03 - loops may occur when node increases rank Global Repair (create new DAG iteration) sequence number establishes event-horize Local Repair (global is not always appropriate) detach/float/merge within a DAG instance Use DAG Hop Timer to color sub-DAG and reduce advertizements Effect was to color the subdag so you wouldn't reattach to someone within your DAG General feedback - fairly complex, not well understood; not implemented Pascal: other effect was to preserve interconnectivity JH: yes 04 - focus on global repair ; drop local repair Asking now, is this too simple? Global re DC: there is still repair through multiple parents JH: still multipath; need to move deeper into the DAG Loop Detection 03 - not discussed, just listed as an issue 04 - several slides on how we do this up routes must increase in rank down routes must decrease in rank We're not detecting "loops", we are generalizing to inconsistency detection and repair A lot of times, don't want to communicate at all unless you have to Use the datapath (incorporate some info in datagram), then go to repair Inconsistancy Detection Repair pass back to parent of no down route exists cleanup stale down routes if dgram is passed back set a bit in datagram; forward back to parent prevents datagram from getting stuck parent drops that route and tries new path Loop Detection and Repair Parent routes fail, use siblings (same rank) Allow at most one (?) sibling hop at a time Need mechanisms to break out of this Moved X number of hops within RANK(now is limited to 1) drop datagram Song Lee: at most one sibling hop; when you have a complex topology may not be enough? will we allow more than one? JH: draft says one, but we recognize that there is a need to support more than one hop DC: natural repair mechanisms should help fix the topology; its not that the "one" choice is bad forever,just that its bad right now; this may have been lost. If a node loses its last parent, once it adjusts rank its prior sibling become candidate parents. Sibling routing is only during the transient. Question: interesting simulations that showed that 1 sibling was enough to make the difference, but other interesting fact from simulation is that we had no way to detect what sibling should be used. Can we afford to use siblings at all? JH: we have a slide on that DC: degree of redundancy and adaptability Pascal: need to poison the route 04 - include routing info in data path instance ID up/down bit senders Rank to assert Rank variant Error bits - think of like a TTL Rank-Error bit - like a ttl of 1 DAO-error bit to backtrack and cleanup state Sibling-Bit - to allow at most one sibling hop; like a ttl of 1 Route flapping avoidance 03 - use a hold down timer 04 - removed: unclear if we needed this given other mechanisms (loop avoidance) do we really need another timer? for now, its removed, no concensus that it was necessary Summary 03 -> 04 remove binding between rpl remove detach/floag/reattach local repair 93 pages to 82 pages... and counting Open Issues OF Not supported node wants to join,but doesn't understand OFx Join and extend using a default OCP requires all nodes to implement OF0 JP asked for concensus - join-as-leaf, will fix in draft-05 Local Repair nodes can move down in the DAG within an instance could create loops and count-to-infinity general concensus is that we need local repair One proposal - use DAG hop timer to wait for poisoning to occur Another - move down at most X ranks within a sequence if things are really bad, must wait for a new sequence DC: another important thing is how these are utilized; if nodes in the DAG below it had other parents, they simply use those. JH: sure Utilize Siblings Three schools of thoughts. 1. No siblings 2. Directional sibling links (only use in one direction) greater generality 3. Bi-directional sibling links equal rank nodes move receiver diversity loop detection and/or error reporting when siblings have no parents No real concensus yet; would like to get feedback on this. MVP (minimum viable protocol) Draft 03 was far too complex Draft 04 removes mechanisms, knobs, hooks Should we simplify more? nearly orthoganal Instance and DAG concepts Backtracking on DAO errors Utilization of sibling links OCP generality What is missing? local repair; address/header compression tradeoff between defining a feature limited base architecture and working "well" out-of-the-box implementation choices are limited lot of discussion among authors around this Some off list comments - how are we going to communicate all this? not enough bandwidth Supporting Drafts metrics applicability statements Objective function specs source routing address/header compression? Next Steps State machine (draft is verbose, not the most concise) clarify the protocol Clarify relationship between neighbor set and candidate parents Specify node operation when OF is not supported Focus on security editorial improvements to make the spec more clear, concise, well organized Questions: Zach Shelby: 1. address compression - we need it in the core spec ; some kind of prefix 2. need to make the draft easier to understand DC: simply codifying document ZS: when talking about prefix, make it clear that it can be a 128 bit address DC: one of the things that 6lowpan introduced, the common case should be carried in essentially zero bits. That technique is not applied here; would you suggest that the simple case should be compact ZS: yes, these are constrained embedded devices JH: identifying what are static vs dynamic and how dynamic with intent at optimizing messages Loa Andersson: was a robust header compression done in rfc3095; have you looked at this? JH: not yet, thats an issue LA: still very much worth looking at DC: generalization of that - where headers have been defined, its not clear if they have been designed to be compactable Anders Brandt: still need to make document smaller; supporting documents - PLEASE still look at point to point DC: essential information on a single issue is distributed throughout the draft; partly reflects a document in transition. One issue that multiple distinct facets of the protocols interact, hopefully in a positive way Song: if you define suboptions; will you define vendor specific JH: currently allow sub options Song: my understanding is that there is a placeholder, but no sub-options are defined JH: right Song: am I free to add any suboptions that you want JH: can't enforce that people won't use sub options for their own purpose; but the intent is to have a framework Michael Richardardson: deals with header compression Emmanuel Baccelli: going in the right direction; have a wayto goes; encourage WG to make the spec slimmer (eg, multiple DAG's?); may be drastic steps to simplify the spec; eg, communicate from root back to sensors and put into a companion doc; at a point where we are running short of time and we really have to make some decisions. DC: clarification - underlying challenge is - its always possible to come up with a particular scenario and fix it with a bit, knob, twist. A lot of whats in here was dealing with Lossy and then don't expect a lot of energy trying to deal with them. Must keep in mind the tradeoff on the particular vs the entire EB: Agree Daniel Bobo: can you address the conversion time and the scalability JH: chose Distance Vector because it reduces state side; but adds looping complexity DB: how scalable in terms of how many nodes? JH: in terms of DAG construction; only need to maintain state on parents; not appending additional information; part that is a bit of an issue is when you are establishing down routes. without any smarts on dealing with aggregation, you are essentially doing host routing so nodes need to maintain state. DB: overhead that is introduced by this JH: what was not talked about was that most of the messages for constucting the DAG is the DIO. A lot of protocols use a fixed rate message. In this case, we used a more adapative approach following the trickle algorithm. Start with a more adaptive period and then decay when you realize things are stable; increase when things are changing. If the routing topology is stable, beacon rate decays to a slow rate. DC: trickle will allow you to not broadcast; don't deal with route flapping; increase rate during times of transition; also means that as you deploy a network that has increased redundancy; there is less work to maintain a viable routing topology Routing Metrics used for Path Calculations in Low Power and Lossy Networks ========================================================================== Mijeom Kim draft-ietf-roll-routing-metrics-03 Introductions ------------- Main objective is to propose a flexible mechanism for advertisement of routing metrics and constraints used by RPL Constraint - used as a filter to prune links and nodes that do not satisfy specific properties Metric - quantatiative valude used to evaluation path quality (referred to as path cost) Best Path - lowest cost path with respect to metrics that satisfies all constraints Emmanual Baccelli: don't understand constraing & metric? MK: some confusion between constraint and metric. Constraint is something you either include or not include. eg, only line powered EB: can this be expressed as a bit? MK: best shown by example Object Common Header Formats C = 1: Constraint, O: Metric O = 1: Optional (only for constraints) A = 0x00: Additive, 0x01: maximum, 0x02: minimum (only for aggregated metrics) G = 1: Global, 0: local (metrics are always global) R = 1: Recorded along with path, 0: aggregated (only for metrics) Node State and Attributes Objects O Flag: Overloaded A Flag: indicates that the node can act as a traffic Aggregator DC: Can you clarify what you mean by traffic aggregator? either - application aggregator; influencing layer 2; layer 3 traffic aggregation? MK: have not specified that yet, but it can be application or traffic aggregator; if a node can act as an aggregator, this bit is set; need to clarify more Node Energy Object T (node type): 0x00 main powered; 0x01 batter powered, 0x02 scavenger I (Included): only for constraint = 1: must be included; 0: must be excluded E (Estimation) when set, the E-E field is value E-E (estimated energy) 8 bit field indicated how much energy is remaining E-E Field in NE Object For scavenging nodes - the power provided by the scavenger divided by the power consumed by the application For battery powerd - the current expected lifetime devided by desired minimum lifetime Hop Count Object - only has hop count for now Throughput and Latency Object Throughput - 32 bits incoded in IEEE floating point format in bytes / second Latency - milliseconds Link Reliability - LQL LQL Object LQL Type 1 - sub object for recorded metrics LQL Type 2 - sub object format for aggregated Link Reliability - ETX (expected transmission count) number of transmissions expected to successfully deliver a packet ETX: 8 bits; ETZ = 1/(Df*Dr) where df: probability that a packet is recieved by the neighbor dr: prob. that ack is received Link Color Object Object format LC Type 1 - global recorded metrics (color/counter) LC Type 2 - constraints (link color) Michael Richardson: ETX is 8 bits (is there an 8 bit floating point number)? MK: sounds like a mistake OF (Objective Function) used by a node to select its parent during DAG building process OCP (Objective Code Point) Object Used to specify the OF and is carried within the DAG metric Next Steps Detailed metric formats and updating schemes Detailed Objective Function (OCP) Clear Distinction of Constraints and Metrics Co-evolve with RPL Teco Boot: wonderful, but complex set of metrics; constrained devices; single DAG. Is this too much now? MK: we are trying to provide a flexible metrics TB: defining the mechanism is not hard; making it work is very hard DC: Maybe a few focused questions. Its hard to create these in the abstract. How will this proposal evolve now that RPL is defined. eg, there are only DIO, DIS and DAO in RPL. This constrains what the objective functions need to work with. Whatever we have here has to be carried. The only time the OF is carried is . Seems that there is a specific set of things we can identify for defining . How you change the rank of a node? How you change the parent & sibling set? Now that we have RPL, we could go back and look at metrics and view it from how it could be used MK: we should make it a shorter list; as I understand it this whole format should be carried i : when does an objective function get invoked? what arrive? what inputs/outputs? How does it change state or packets? Then we can identify the set of objective functions. Have to do with computing new rank, adjusting sibling set; IF we narrow down DAG instance, that could simplity it further. Ulrich Herberg: might be too complicated and overdone; why not a single dimensionless value? Why so many comp MK: different applications and scenarios so they can define a few for a specific UH: can these be comined into a single field? DC: what is MVP? How much flexibility? Obligation to do careful upfront analysis so we have only what we need Emmanual Baccelli: share concerns and how can we get to a slimmer spec? Would like to see the definition of constraint that will clearly differentiate it from a boolean. MK: difference between metric and constraint? EB: yes, don't understand the difference MK: first slide; constraint is a filter to tune out; metrics are used to select the path DC: offered a definition - first to prune parent set; second to compute the rank MK: constraing - whether we select or not; Jabber: throughput and latency have a wide range; is floating point required? Teco Boot: does this work on classify traffic? DC: where would the choice of selecting a set of metrics translate into picking the next DAG DC: in principal you could associate them ; roots of a dag to establish a preference to that dag within the instance DC: how is that choice of preference determined? unclear? RPL defines how traffic gets associated with a DAG instance Dave Oran: made an assertion that it is specified how to make decision; did not see it anywhere Dave Oran: there is a mechanism; big problem here is that if the decision on how the packet gets on a DAG is made at each node; need to do the binding where a packet enters the dag and make sure its consistent; otherwise packets could switch dags in the middle of ; seems to be a big hole in the architecture; DC: area that needs to be codified; whole mechanism needsd Sung Lee: didn't completely understand how the aggretators worked together; flexible on the surface; need to know how it translates to an OB that you can use to build a dag MK: need to specify how this will work; depends on applications and scenarios and depends on implementor Sung Lee: thought that objective function is going to guide how to ensure interoperability MK: for some application may want to use throughput; others may want to include other constraint; should be specified DC: if there is to be a selection made, must be clear how Dave Oram: constraint is stronger given the type of equipmenet; can't rely on injecting policy so they make individual decisions about how to modify the forwarding table; it just won't work. Has to be done on ingress. Something like MPLS. Cisco has a product with this bug. DC: share your concern Jabber: is there a method for negotiation metrics? DC: not as currently defined Reflections on Security Architectural Framework RoLL ==================================================== Rene Struik Good to reflect on what is in the draft and not in the draft. Diverse deployment scenarios Home, building, urban, industrial control Idealized security design goal unified security architecture that fits these scenarios concise set of crypto & security mechanisms -eg use what can fit into hardware (or what exists) AES block single policy framework configuration parameters application dependent Allows for mass-scale production; still allowing customization General Security Objectives Trust in other node Trust in node's info->separation between communication subsystem and sensor Trust in own: physical security Dave Oram: when you use the word trust unqualified, I get confused. In routing, what do you have to trust the node for? Could you try to drill down a level. What are you worried about? DC: requirement is for routing security Dave Oram: that's not well formed either RS: trust is a vague statement Basic Security Services Suitable combination of confidentiality authenticity non repudiation replay protection timeliness Logical granularity determined by key type (link key, group key, network wide key) Notes CIA less important than AIC Timeliness/replay protection prevents stale/duplicate messages need to facilitate suitable combinations (parm settings) using same generic constructs Considerations for Lossy, Sleepy, Philantropic Networks Sync/recovery of state setup of link with unknown neighbor detection of missing devices Example topics stale routing tables how to resolve route to nowhere what about autonomous updates and resolution of routing errors? Further considerations Support for topology / role changes role change - much intelligence may reside in device device enrollment Note: may necessitate peer to peer traffic (MP to P may be unwieldy) Support for heterogeneous trust domains and enforcement of security policy This may require use of multicast/group keys; rathter than network wide keys Cross layer issues Keying material Device identities vs addresses device roles security policy parameters I/O parameters Notes: devices roles and authorization require reasoning about devices using a physical id really need to bind identifies with keying material at manufacturing Further notes Non tamper, low cost proof devices Tamper evidencing how to detect device compromise Resource exhaustion to do crypto Computations on incoming traffic should not burn the battery Next Steps Revise routing security document, taking into account draft-tsao-roll-security-framework-01 and suggestions given here Jabber QUestions: detection of ; having a unique id does not help Robert Cragie: from a routing perspective; nodes own intepretation of quality; anecdotal patterns can be useful DC: most pressing question is how do we get the security considers to help drive RPL? DC: allow RPL to drive ; metrics & security should take into account what; is there authenticity, confidentiality; we can take this into a concrete discussion RS: yes, good next step; needs to be a home DC: agree, beauty of this is that ROLL can focus on a piece of this (routing portion) in a manner that is consistent with larger picture